* [PATCH AUTOSEL 4.19 023/258] powerpc/pseries: add of_node_put() in dlpar_detach_node()
From: Sasha Levin @ 2019-01-28 15:55 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev, Frank Rowand
In-Reply-To: <20190128155924.51521-1-sashal@kernel.org>
From: Frank Rowand <frank.rowand@sony.com>
[ Upstream commit 5b3f5c408d8cc59b87e47f1ab9803dbd006e4a91 ]
The previous commit, "of: overlay: add missing of_node_get() in
__of_attach_node_sysfs" added a missing of_node_get() to
__of_attach_node_sysfs(). This results in a refcount imbalance
for nodes attached with dlpar_attach_node(). The calling sequence
from dlpar_attach_node() to __of_attach_node_sysfs() is:
dlpar_attach_node()
of_attach_node()
__of_attach_node_sysfs()
For more detailed description of the node refcount, see
commit 68baf692c435 ("powerpc/pseries: Fix of_node_put() underflow
during DLPAR remove").
Tested-by: Alan Tull <atull@kernel.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/dlpar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index a0b20c03f078..e3010b14aea5 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -272,6 +272,8 @@ int dlpar_detach_node(struct device_node *dn)
if (rc)
return rc;
+ of_node_put(dn);
+
return 0;
}
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 291/304] block/swim3: Fix regression on PowerBook G3
From: Sasha Levin @ 2019-01-28 15:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jens Axboe, Sasha Levin, linuxppc-dev, linux-block, Finn Thain
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Finn Thain <fthain@telegraphics.com.au>
[ Upstream commit 427c5ce4417cba0801fbf79c8525d1330704759c ]
As of v4.20, the swim3 driver crashes when loaded on a PowerBook G3
(Wallstreet).
MacIO PCI driver attached to Gatwick chipset
MacIO PCI driver attached to Heathrow chipset
swim3 0.00015000:floppy: [fd0] SWIM3 floppy controller in media bay
0.00013020:ch-a: ttyS0 at MMIO 0xf3013020 (irq = 16, base_baud = 230400) is a Z85c30 ESCC - Serial port
0.00013000:ch-b: ttyS1 at MMIO 0xf3013000 (irq = 17, base_baud = 230400) is a Z85c30 ESCC - Infrared port
macio: fixed media-bay irq on gatwick
macio: fixed left floppy irqs
swim3 1.00015000:floppy: [fd1] Couldn't request interrupt
Unable to handle kernel paging request for data at address 0x00000024
Faulting instruction address: 0xc02652f8
Oops: Kernel access of bad area, sig: 11 [#1]
BE SMP NR_CPUS=2 PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0 #2
NIP: c02652f8 LR: c026915c CTR: c0276d1c
REGS: df43ba10 TRAP: 0300 Not tainted (4.20.0)
MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28228288 XER: 00000100
DAR: 00000024 DSISR: 40000000
GPR00: c026915c df43bac0 df439060 c0731524 df494700 00000000 c06e1c08 00000001
GPR08: 00000001 00000000 df5ff220 00001032 28228282 00000000 c0004ca4 00000000
GPR16: 00000000 00000000 00000000 c073144c dfffe064 c0731524 00000120 c0586108
GPR24: c073132c c073143c c073143c 00000000 c0731524 df67cd70 df494700 00000001
NIP [c02652f8] blk_mq_free_rqs+0x28/0xf8
LR [c026915c] blk_mq_sched_tags_teardown+0x58/0x84
Call Trace:
[df43bac0] [c0045f50] flush_workqueue_prep_pwqs+0x178/0x1c4 (unreliable)
[df43bae0] [c026915c] blk_mq_sched_tags_teardown+0x58/0x84
[df43bb00] [c02697f0] blk_mq_exit_sched+0x9c/0xb8
[df43bb20] [c0252794] elevator_exit+0x84/0xa4
[df43bb40] [c0256538] blk_exit_queue+0x30/0x50
[df43bb50] [c0256640] blk_cleanup_queue+0xe8/0x184
[df43bb70] [c034732c] swim3_attach+0x330/0x5f0
[df43bbb0] [c034fb24] macio_device_probe+0x58/0xec
[df43bbd0] [c032ba88] really_probe+0x1e4/0x2f4
[df43bc00] [c032bd28] driver_probe_device+0x64/0x204
[df43bc20] [c0329ac4] bus_for_each_drv+0x60/0xac
[df43bc50] [c032b824] __device_attach+0xe8/0x160
[df43bc80] [c032ab38] bus_probe_device+0xa0/0xbc
[df43bca0] [c0327338] device_add+0x3d8/0x630
[df43bcf0] [c0350848] macio_add_one_device+0x444/0x48c
[df43bd50] [c03509f8] macio_pci_add_devices+0x168/0x1bc
[df43bd90] [c03500ec] macio_pci_probe+0xc0/0x10c
[df43bda0] [c02ad884] pci_device_probe+0xd4/0x184
[df43bdd0] [c032ba88] really_probe+0x1e4/0x2f4
[df43be00] [c032bd28] driver_probe_device+0x64/0x204
[df43be20] [c032bfcc] __driver_attach+0x104/0x108
[df43be40] [c0329a00] bus_for_each_dev+0x64/0xb4
[df43be70] [c032add8] bus_add_driver+0x154/0x238
[df43be90] [c032ca24] driver_register+0x84/0x148
[df43bea0] [c0004aa0] do_one_initcall+0x40/0x188
[df43bf00] [c0690100] kernel_init_freeable+0x138/0x1d4
[df43bf30] [c0004cbc] kernel_init+0x18/0x10c
[df43bf40] [c00121e4] ret_from_kernel_thread+0x14/0x1c
Instruction dump:
5484d97e 4bfff4f4 9421ffe0 7c0802a6 bf410008 7c9e2378 90010024 8124005c
2f890000 419e0078 81230004 7c7c1b78 <81290024> 2f890000 419e0064 81440000
---[ end trace 12025ab921a9784c ]---
Reverting commit 8ccb8cb1892b ("swim3: convert to blk-mq") resolves the
problem.
That commit added a struct blk_mq_tag_set to struct floppy_state and
initialized it with a blk_mq_init_sq_queue() call. Unfortunately, there
is a memset() in swim3_add_device() that subsequently clears the
floppy_state struct. That means fs->tag_set->ops is a NULL pointer, and
it gets dereferenced by blk_mq_free_rqs() which gets called in the
request_irq() error path. Move the memset() to fix this bug.
BTW, the request_irq() failure for the left mediabay floppy (fd1) is not
a regression. I don't know why it happens. The right media bay floppy
(fd0) works fine however.
Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
Fixes: 8ccb8cb1892b ("swim3: convert to blk-mq")
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/swim3.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index 3f6df3f1f5d9..1046459f172b 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -1091,8 +1091,6 @@ static int swim3_add_device(struct macio_dev *mdev, int index)
struct floppy_state *fs = &floppy_states[index];
int rc = -EBUSY;
- /* Do this first for message macros */
- memset(fs, 0, sizeof(*fs));
fs->mdev = mdev;
fs->index = index;
@@ -1192,14 +1190,15 @@ static int swim3_attach(struct macio_dev *mdev,
return rc;
}
- fs = &floppy_states[floppy_count];
-
disk = alloc_disk(1);
if (disk == NULL) {
rc = -ENOMEM;
goto out_unregister;
}
+ fs = &floppy_states[floppy_count];
+ memset(fs, 0, sizeof(*fs));
+
disk->queue = blk_mq_init_sq_queue(&fs->tag_set, &swim3_mq_ops, 2,
BLK_MQ_F_SHOULD_MERGE);
if (IS_ERR(disk->queue)) {
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 286/304] block/swim3: Fix -EBUSY error when re-opening device after unmount
From: Sasha Levin @ 2019-01-28 15:43 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jens Axboe, Sasha Levin, linuxppc-dev, linux-block, Finn Thain
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Finn Thain <fthain@telegraphics.com.au>
[ Upstream commit 296dcc40f2f2e402facf7cd26cf3f2c8f4b17d47 ]
When the block device is opened with FMODE_EXCL, ref_count is set to -1.
This value doesn't get reset when the device is closed which means the
device cannot be opened again. Fix this by checking for refcount <= 0
in the release method.
Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/block/swim3.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/block/swim3.c b/drivers/block/swim3.c
index c1c676a33e4a..3f6df3f1f5d9 100644
--- a/drivers/block/swim3.c
+++ b/drivers/block/swim3.c
@@ -995,7 +995,11 @@ static void floppy_release(struct gendisk *disk, fmode_t mode)
struct swim3 __iomem *sw = fs->swim3;
mutex_lock(&swim3_mutex);
- if (fs->ref_count > 0 && --fs->ref_count == 0) {
+ if (fs->ref_count > 0)
+ --fs->ref_count;
+ else if (fs->ref_count == -1)
+ fs->ref_count = 0;
+ if (fs->ref_count == 0) {
swim3_action(fs, MOTOR_OFF);
out_8(&sw->control_bic, 0xff);
swim3_select(fs, RELAX);
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 258/304] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Mahesh Salgaonkar, linuxppc-dev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[ Upstream commit 0db6896ff6332ba694f1e61b93ae3b2640317633 ]
For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. Now that fadump uses CMA for reserved
area, this memory area is now not protected from hot-remove operations
unless it is cma allocated. Hence, fadump service can fail to re-register
after the hot-remove operation, if hot-removed memory belongs to fadump
reserved region. To avoid this make sure that memory from fadump reserved
area is not hot-removable if fadump is registered.
However, if user still wants to remove that memory, he can do so by
manually stopping fadump service before hot-remove operation.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/fadump.h | 2 +-
arch/powerpc/kernel/fadump.c | 10 ++++++++--
arch/powerpc/platforms/pseries/hotplug-memory.c | 7 +++++--
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 1e7a33592e29..15bc07a31c46 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -200,7 +200,7 @@ struct fad_crash_memory_ranges {
unsigned long long size;
};
-extern int is_fadump_boot_memory_area(u64 addr, ulong size);
+extern int is_fadump_memory_area(u64 addr, ulong size);
extern int early_init_dt_scan_fw_dump(unsigned long node,
const char *uname, int depth, void *data);
extern int fadump_reserve_mem(void);
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 761b28b1427d..7fd9b3e1fa39 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -118,13 +118,19 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
/*
* If fadump is registered, check if the memory provided
- * falls within boot memory area.
+ * falls within boot memory area and reserved memory area.
*/
-int is_fadump_boot_memory_area(u64 addr, ulong size)
+int is_fadump_memory_area(u64 addr, ulong size)
{
+ u64 d_start = fw_dump.reserve_dump_area_start;
+ u64 d_end = d_start + fw_dump.reserve_dump_area_size;
+
if (!fw_dump.dump_registered)
return 0;
+ if (((addr + size) > d_start) && (addr <= d_end))
+ return 1;
+
return (addr + size) > RMA_START && addr <= fw_dump.boot_memory_size;
}
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 2a983b5a52e1..2318ab29d5dd 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -355,8 +355,11 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
phys_addr = lmb->base_addr;
#ifdef CONFIG_FA_DUMP
- /* Don't hot-remove memory that falls in fadump boot memory area */
- if (is_fadump_boot_memory_area(phys_addr, block_sz))
+ /*
+ * Don't hot-remove memory that falls in fadump boot memory area
+ * and memory that is reserved for capturing old kernel memory.
+ */
+ if (is_fadump_memory_area(phys_addr, block_sz))
return false;
#endif
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 253/304] powerpc/mm: Fix reporting of kernel execute faults on the 8xx
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: linuxppc-dev, Sasha Levin
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit ffca395b11c4a5a6df6d6345f794b0e3d578e2d0 ]
On the 8xx, no-execute is set via PPP bits in the PTE. Therefore
a no-exec fault generates DSISR_PROTFAULT error bits,
not DSISR_NOEXEC_OR_G.
This patch adds DSISR_PROTFAULT in the test mask.
Fixes: d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute faults")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/mm/fault.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 1697e903bbf2..50e5c790d11e 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -226,7 +226,9 @@ static int mm_fault_error(struct pt_regs *regs, unsigned long addr,
static bool bad_kernel_fault(bool is_exec, unsigned long error_code,
unsigned long address)
{
- if (is_exec && (error_code & (DSISR_NOEXEC_OR_G | DSISR_KEYFAULT))) {
+ /* NX faults set DSISR_PROTFAULT on the 8xx, DSISR_NOEXEC_OR_G on others */
+ if (is_exec && (error_code & (DSISR_NOEXEC_OR_G | DSISR_KEYFAULT |
+ DSISR_PROTFAULT))) {
printk_ratelimited(KERN_CRIT "kernel tried to execute"
" exec-protected page (%lx) -"
"exploit attempt? (uid: %d)\n",
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 235/304] powerpc/powernv/ioda: Allocate indirect TCE levels of cached userspace addresses on demand
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Alexey Kardashevskiy, linuxppc-dev, Sasha Levin
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Alexey Kardashevskiy <aik@ozlabs.ru>
[ Upstream commit bdbf649efe21173cae63b4b71db84176420f9039 ]
The powernv platform maintains 2 TCE tables for VFIO - a hardware TCE
table and a table with userspace addresses; the latter is used for
marking pages dirty when corresponging TCEs are unmapped from
the hardware table.
a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels
on demand") enabled on-demand allocation of the hardware table,
however it missed the other table so it has still been fully allocated
at the boot time. This fixes the issue by allocating a single level,
just like we do for the hardware table.
Fixes: a68bd1267b72 ("powerpc/powernv/ioda: Allocate indirect TCE levels on demand")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda-tce.c b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
index fe9691040f54..7639b2168755 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda-tce.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda-tce.c
@@ -299,7 +299,7 @@ long pnv_pci_ioda2_table_alloc_pages(int nid, __u64 bus_offset,
if (alloc_userspace_copy) {
offset = 0;
uas = pnv_pci_ioda2_table_do_alloc_pages(nid, level_shift,
- levels, tce_table_size, &offset,
+ tmplevels, tce_table_size, &offset,
&total_allocated_uas);
if (!uas)
goto free_tces_exit;
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 233/304] powerpc/perf: Fix thresholding counter data for unknown type
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
[ Upstream commit 17cfccc91545682513541924245abb876d296063 ]
MMCRA[34:36] and MMCRA[38:44] expose the thresholding counter value.
Thresholding counter can be used to count latency cycles such as
load miss to reload. But threshold counter value is not relevant
when the sampled instruction type is unknown or reserved. Patch to
fix the thresholding counter value to zero when sampled instruction
type is unknown or reserved.
Fixes: 170a315f41c6('powerpc/perf: Support to export MMCRA[TEC*] field to userspace')
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/perf/isa207-common.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 177de814286f..6a2f65d3d088 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -226,8 +226,13 @@ void isa207_get_mem_weight(u64 *weight)
u64 mmcra = mfspr(SPRN_MMCRA);
u64 exp = MMCRA_THR_CTR_EXP(mmcra);
u64 mantissa = MMCRA_THR_CTR_MANT(mmcra);
+ u64 sier = mfspr(SPRN_SIER);
+ u64 val = (sier & ISA207_SIER_TYPE_MASK) >> ISA207_SIER_TYPE_SHIFT;
- *weight = mantissa << (2 * exp);
+ if (val == 0 || val == 7)
+ *weight = 0;
+ else
+ *weight = mantissa << (2 * exp);
}
int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 222/304] powerpc/uaccess: fix warning/error with access_ok()
From: Sasha Levin @ 2019-01-28 15:42 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: linuxppc-dev, Sasha Levin
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Christophe Leroy <christophe.leroy@c-s.fr>
[ Upstream commit 05a4ab823983d9136a460b7b5e0d49ee709a6f86 ]
With the following piece of code, the following compilation warning
is encountered:
if (_IOC_DIR(ioc) != _IOC_NONE) {
int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ;
if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) {
drivers/platform/test/dev.c: In function 'my_ioctl':
drivers/platform/test/dev.c:219:7: warning: unused variable 'verify' [-Wunused-variable]
int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ;
This patch fixes it by referencing 'type' in the macro allthough
doing nothing with it.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 15bea9a0f260..ebc0b916dcf9 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -63,7 +63,7 @@ static inline int __access_ok(unsigned long addr, unsigned long size,
#endif
#define access_ok(type, addr, size) \
- (__chk_user_ptr(addr), \
+ (__chk_user_ptr(addr), (void)(type), \
__access_ok((__force unsigned long)(addr), (size), get_fs()))
/*
--
2.19.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.20 181/304] KVM: PPC: Book3S: Only report KVM_CAP_SPAPR_TCE_VFIO on powernv machines
From: Sasha Levin @ 2019-01-28 15:41 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linuxppc-dev, kvm-ppc, Suraj Jitindar Singh
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
[ Upstream commit 693ac10a88a2219bde553b2e8460dbec97e594e6 ]
The kvm capability KVM_CAP_SPAPR_TCE_VFIO is used to indicate the
availability of in kernel tce acceleration for vfio. However it is
currently the case that this is only available on a powernv machine,
not for a pseries machine.
Thus make this capability dependent on having the cpu feature
CPU_FTR_HVMODE.
[paulus@ozlabs.org - fixed compilation for Book E.]
Signed-off-by: Suraj Jitindar Singh <sjitindarsingh@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kvm/powerpc.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 2869a299c4ed..75e2e471442f 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -543,8 +543,11 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
#ifdef CONFIG_PPC_BOOK3S_64
case KVM_CAP_SPAPR_TCE:
case KVM_CAP_SPAPR_TCE_64:
- /* fallthrough */
+ r = 1;
+ break;
case KVM_CAP_SPAPR_TCE_VFIO:
+ r = !!cpu_has_feature(CPU_FTR_HVMODE);
+ break;
case KVM_CAP_PPC_RTAS:
case KVM_CAP_PPC_FIXUP_HCALL:
case KVM_CAP_PPC_ENABLE_HCALL:
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v4] kbuild: Add support for DT binding schema checks
From: Rob Herring @ 2019-01-28 15:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Kumar Gala, arm-soc, Sean Hudson, Jonathan Corbet, linuxppc-dev,
open list:DOCUMENTATION, Linux Kernel Mailing List, linux-kbuild,
Masahiro Yamada, Grant Likely, Michal Marek, Frank Rowand,
Linux ARM
In-Reply-To: <CAMuHMdU3Om44R3wB69jeyHFER8syGDeJQsYd-pXqEKHBMZW2ow@mail.gmail.com>
On Mon, Jan 28, 2019 at 2:59 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Sun, Jan 27, 2019 at 4:00 AM Rob Herring <robh@kernel.org> wrote:
> > On Wed, Jan 23, 2019 at 9:33 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Dec 11, 2018 at 9:24 PM Rob Herring <robh@kernel.org> wrote:
> > > > This adds the build infrastructure for checking DT binding schema
> > > > documents and validating dts files using the binding schema.
> > > >
> > > > Check DT binding schema documents:
> > > > make dt_binding_check
> > > >
> > > > Build dts files and check using DT binding schema:
> > > > make dtbs_check
> > > >
> > > > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> > > > use for validation. This makes it easier to find and fix errors
> > > > generated by a specific schema.
> > > >
> > > > Currently, the validation targets are separate from a normal build to
> > > > avoid a hard dependency on the external DT schema project and because
> > > > there are lots of warnings generated.
> > >
> > > Thanks, I'm giving this a try, and get errors like:
> > >
> > > DTC arch/arm/boot/dts/emev2-kzm9d.dt.yaml
> > > FATAL ERROR: No markers present in property 'cpu0' value
> > >
> > > and
> > >
> > > DTC arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dt.yaml
> > > FATAL ERROR: No markers present in property 'audio_clk_a' value
> > >
> > > Do you have a clue?
> >
> > That's really strange because those aren't even properties. Are other
> > dts files okay? This is the in tree dtc?
> >
> > The only time you should be missing markers is if you did a dts -> dts
> > -> dt.yaml.
>
> Found it: make dtbs_check doesn't play well with my local change to
> add symbols for DT overlays:
Now that makes sense.
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -285,6 +285,10 @@ cmd_dt_S_dtb=
> \
> $(obj)/%.dtb.S: $(obj)/%.dtb FORCE
> $(call if_changed,dt_S_dtb)
>
> +ifeq ($(CONFIG_OF_OVERLAY),y)
> +DTC_FLAGS += -@
> +endif
> +
> quiet_cmd_dtc = DTC $@
> cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o
> $(dtc-tmp) $< ; \
>
> Do you see a way to handle that better?
We need to have the code that generates these properties to also add
markers. Or we could drop the __symbols__ nodes on YAML output. Or
ignore the option when doing YAML output.
> Apart from a few expected issues, I'm seeing one other strange message:
>
> arch/arm/boot/dts/sh73a0-kzm9g.dt.yaml: interrupts: [[2, 4], [3,
> 4]] is too long
>
> This is the interrupts property in the adi,adxl345 node in
> arch/arm/boot/dts/sh73a0-kzm9g.dts.
> Apparently the check complains if more than one interrupt is listed here.
> Is this a known issue?
There are lots of warnings... I've gone thru and checked some to make
sure they are valid, but certainly not all. There's probably some
cases that are too strict too.
This one is because this device is listed in trivial-devices.yaml and
you can't have 2 interrupts for a trivial device (because you need to
define the interrupt order). Looks like we have a binding doc for it
too, so we should just remove it from trivial-devices.yaml.
There are lots of '... is too (long|short)' messages because of how
the dts file property values are bracketed. This used to not matter,
but is significant in the YAML output. I have a dtc patch to give
warnings on all these (and dtc will give source location).
Rob
^ permalink raw reply
* [PATCH AUTOSEL 4.20 078/304] powerpc/32: Add .data..Lubsan_data*/.data..Lubsan_type* sections explicitly
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Mathieu Malaterre, linuxppc-dev, Sasha Levin
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Mathieu Malaterre <malat@debian.org>
[ Upstream commit beba24ac59133cb36ecd03f9af9ccb11971ee20e ]
When both `CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y` and `CONFIG_UBSAN=y`
are set, link step typically produce numberous warnings about orphan
section:
+ powerpc-linux-gnu-ld -EB -m elf32ppc -Bstatic --orphan-handling=warn --build-id --gc-sections -X -o .tmp_vmlinux1 -T ./arch/powerpc/kernel/vmlinux.lds --who
le-archive built-in.a --no-whole-archive --start-group lib/lib.a --end-group
powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data393' from `init/main.o' being placed in section `.data..Lubsan_data393'.
powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_data394' from `init/main.o' being placed in section `.data..Lubsan_data394'.
...
powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type11' from `init/main.o' being placed in section `.data..Lubsan_type11'.
powerpc-linux-gnu-ld: warning: orphan section `.data..Lubsan_type12' from `init/main.o' being placed in section `.data..Lubsan_type12'.
...
This commit remove those warnings produced at W=1.
Link: https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg135407.html
Suggested-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mathieu Malaterre <malat@debian.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/kernel/vmlinux.lds.S | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 434581bcd5b4..1148c3c60c3b 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -308,6 +308,10 @@ SECTIONS
#ifdef CONFIG_PPC32
.data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
+#ifdef CONFIG_UBSAN
+ *(.data..Lubsan_data*)
+ *(.data..Lubsan_type*)
+#endif
*(.data.rel*)
*(SDATA_MAIN)
*(.sdata2)
--
2.19.1
^ permalink raw reply related
* Re: [REPOST PATCH v08 0/5] powerpc/hotplug: Update affinity for migrated CPUs
From: Michael Bringmann @ 2019-01-28 15:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Nathan Fontenot, Thomas Falcon, Tyrel Datwyler, John Allen
In-Reply-To: <20180821153335.4955.44734.stgit@ltcalpine2-lp9.aus.stglabs.ibm.com>
On 8/21/18 10:33 AM, mwb@linux.vnet.ibm.com wrote:
> The migration of LPARs across Power systems affects many attributes
> including that of the associativity of CPUs. The patches in this
> set execute when a system is coming up fresh upon a migration target.
> They are intended to,
>
> * Recognize changes to the associativity of CPUs recorded in internal
> data structures when compared to the latest copies in the device tree.
> * Generate calls to other code layers to reset the data structures
> related to associativity of the CPUs.
> * Re-register the 'changed' entities into the target system.
> Re-registration of CPUs mostly entails acting as if they have been
> newly hot-added into the target system.
>
> Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Retract this series in preference to
[PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
Michael
>
> Michael Bringmann (5):
> hotplug/cpu: Conditionally acquire/release DRC index
> hotplug/cpu: Add operation queuing function
> hotplug/cpu: Provide CPU readd operation
> mobility/numa: Ensure numa update does not overlap
> hotplug/pmt: Update topology after PMT
> ---
> Changes in patch:
> -- Restructure and rearrange content of patches to co-locate
> similar or related modifications
> -- Rename pseries_update_drconf_cpu to pseries_update_processor
> -- Simplify code to update CPU nodes during mobility checks.
> Remove functions to generate extra HP_ELOG messages in favor
> of direct function calls to dlpar_cpu_readd_by_index.
> -- Revise code order in dlpar_cpu_readd_by_index() to present
> more appropriate error codes from underlying layers of the
> implementation.
> -- Add hotplug device lock around all property updates
> -- Add call to rebuild_sched_domains in case of changes
> -- Various code cleanups and compaction
> -- Rebase to 4.18 kernel
> -- Change operation to run CPU readd after end of migration store.
> -- Improve descriptive text
> -- Cleanup patch reference to outdated function
> -- Code cleanup a 'acquire_drc' check in dlpar_cpu_add.
> -- Code cleanup a 'release_drc' check in dlpar_cpu_remove.
> -- Add more information to patch descriptions.
> -- More code cleanup
> -- Rearrange call to rebuild_sched_domains to allow removal
> of some locking code.
>
--
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line 363-5196
External: (512) 286-5196
Cell: (512) 466-0650
mwb@linux.vnet.ibm.com
^ permalink raw reply
* [PATCH AUTOSEL 4.20 027/304] powerpc/pseries: add of_node_put() in dlpar_detach_node()
From: Sasha Levin @ 2019-01-28 15:39 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Sasha Levin, linuxppc-dev, Frank Rowand
In-Reply-To: <20190128154341.47195-1-sashal@kernel.org>
From: Frank Rowand <frank.rowand@sony.com>
[ Upstream commit 5b3f5c408d8cc59b87e47f1ab9803dbd006e4a91 ]
The previous commit, "of: overlay: add missing of_node_get() in
__of_attach_node_sysfs" added a missing of_node_get() to
__of_attach_node_sysfs(). This results in a refcount imbalance
for nodes attached with dlpar_attach_node(). The calling sequence
from dlpar_attach_node() to __of_attach_node_sysfs() is:
dlpar_attach_node()
of_attach_node()
__of_attach_node_sysfs()
For more detailed description of the node refcount, see
commit 68baf692c435 ("powerpc/pseries: Fix of_node_put() underflow
during DLPAR remove").
Tested-by: Alan Tull <atull@kernel.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/powerpc/platforms/pseries/dlpar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c b/arch/powerpc/platforms/pseries/dlpar.c
index 7625546caefd..17958043e7f7 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -270,6 +270,8 @@ int dlpar_detach_node(struct device_node *dn)
if (rc)
return rc;
+ of_node_put(dn);
+
return 0;
}
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v4] kbuild: Add support for DT binding schema checks
From: Geert Uytterhoeven @ 2019-01-28 15:43 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Kumar Gala, arm-soc, Sean Hudson, Jonathan Corbet, linuxppc-dev,
open list:DOCUMENTATION, Linux Kernel Mailing List, linux-kbuild,
Masahiro Yamada, Grant Likely, Michal Marek, Frank Rowand,
Linux ARM
In-Reply-To: <CAL_JsqKG8d+yONY2ikeiCaORYBfWhLe_rAsir11R8zRAD84MmA@mail.gmail.com>
Hi Rob,
On Mon, Jan 28, 2019 at 4:35 PM Rob Herring <robh@kernel.org> wrote:
> On Mon, Jan 28, 2019 at 3:43 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Dec 11, 2018 at 9:24 PM Rob Herring <robh@kernel.org> wrote:
> > > This adds the build infrastructure for checking DT binding schema
> > > documents and validating dts files using the binding schema.
> > >
> > > Check DT binding schema documents:
> > > make dt_binding_check
> > >
> > > Build dts files and check using DT binding schema:
> > > make dtbs_check
> > >
> > > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> > > use for validation. This makes it easier to find and fix errors
> > > generated by a specific schema.
> > >
> > > Currently, the validation targets are separate from a normal build to
> > > avoid a hard dependency on the external DT schema project and because
> > > there are lots of warnings generated.
> > BTW, what are the CONFIG dependencies for this to work?
> > E.g. defconfig on x86_64 fails, even after enabling CONFIG_OF:
>
> I generally use allmodconfig which enables building all DTs.
>
> Yes, there's a dependency on CONFIG_DTC which isn't always enabled
> with CONFIG_OF. Maybe it should be. The only other solutions I've
Oh, didn't think of CONFIG_DTC.
> thought of are either always build dtc or make the targets conditional
> on CONFIG_DTC. The latter would only change the error message.
Making the target conditional may make it more obvious to the user
what's going on. Cfr. "make modules_install" giving a nice explanation
when CONFIG_MODULES=n.
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
* Re: [PATCH] powerpc/pseries: Perform full re-add of CPU for topology update post-migration
From: Michael Bringmann @ 2019-01-28 15:41 UTC (permalink / raw)
To: Nathan Fontenot, linuxppc-dev; +Cc: ldufour
In-Reply-To: <154083861636.18916.18172276232185726281.stgit@ltcalpine2-lp14.aus.stglabs.ibm.com>
On 10/29/18 1:43 PM, Nathan Fontenot wrote:
> On pseries systems, performing a partition migration can result in
> altering the nodes a CPU is assigned to on the destination system. For
> exampl, pre-migration on the source system CPUs are in node 1 and 3,
> post-migration on the destination system CPUs are in nodes 2 and 3.
>
> Handling the node change for a CPU can cause corruption in the slab
> cache if we hit a timing where a CPUs node is changed while cache_reap()
> is invoked. The corruption occurs because the slab cache code appears
> to rely on the CPU and slab cache pages being on the same node.
>
> The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
> does not prevent us from hitting this scenario.
>
> Changing the device tree property update notification handler that
> recognizes an affinity change for a CPU to do a full DLPAR remove and
> add of the CPU instead of dynamically changing its node resolves this
> issue.
>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/topology.h | 2 ++
> arch/powerpc/mm/numa.c | 9 +--------
> arch/powerpc/platforms/pseries/hotplug-cpu.c | 19 +++++++++++++++++++
> 3 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/topology.h b/arch/powerpc/include/asm/topology.h
> index a4a718dbfec6..f85e2b01c3df 100644
> --- a/arch/powerpc/include/asm/topology.h
> +++ b/arch/powerpc/include/asm/topology.h
> @@ -132,6 +132,8 @@ static inline void shared_proc_topology_init(void) {}
> #define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu))
> #define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu))
> #define topology_core_id(cpu) (cpu_to_core_id(cpu))
> +
> +int dlpar_cpu_readd(int cpu);
> #endif
> #endif
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 693ae1c1acba..bb6a7b56bef7 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1461,13 +1461,6 @@ static void reset_topology_timer(void)
>
> #ifdef CONFIG_SMP
>
> -static void stage_topology_update(int core_id)
> -{
> - cpumask_or(&cpu_associativity_changes_mask,
> - &cpu_associativity_changes_mask, cpu_sibling_mask(core_id));
> - reset_topology_timer();
> -}
> -
> static int dt_update_callback(struct notifier_block *nb,
> unsigned long action, void *data)
> {
> @@ -1480,7 +1473,7 @@ static int dt_update_callback(struct notifier_block *nb,
> !of_prop_cmp(update->prop->name, "ibm,associativity")) {
> u32 core_id;
> of_property_read_u32(update->dn, "reg", &core_id);
> - stage_topology_update(core_id);
> + rc = dlpar_cpu_readd(core_id);
> rc = NOTIFY_OK;
> }
> break;
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index 2f8e62163602..97feb6e79f1a 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -802,6 +802,25 @@ static int dlpar_cpu_add_by_count(u32 cpus_to_add)
> return rc;
> }
>
> +int dlpar_cpu_readd(int cpu)
> +{
> + struct device_node *dn;
> + struct device *dev;
> + u32 drc_index;
> + int rc;
> +
> + dev = get_cpu_device(cpu);
> + dn = dev->of_node;
> +
> + rc = of_property_read_u32(dn, "ibm,my-drc-index", &drc_index);
> +
> + rc = dlpar_cpu_remove_by_index(drc_index);
> + if (!rc)
> + rc = dlpar_cpu_add(drc_index);
> +
> + return rc;
> +}
> +
> int dlpar_cpu(struct pseries_hp_errorlog *hp_elog)
> {
> u32 count, drc_index;
>
>
--
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line 363-5196
External: (512) 286-5196
Cell: (512) 466-0650
mwb@linux.vnet.ibm.com
^ permalink raw reply
* Re: [PATCH v4] kbuild: Add support for DT binding schema checks
From: Rob Herring @ 2019-01-28 15:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Kumar Gala, arm-soc, Sean Hudson, Jonathan Corbet, linuxppc-dev,
open list:DOCUMENTATION, Linux Kernel Mailing List, linux-kbuild,
Masahiro Yamada, Grant Likely, Michal Marek, Frank Rowand,
Linux ARM
In-Reply-To: <CAMuHMdUdGvBUX7EsOrwJM4_LzR_Pe2exJ1Pfo48Vt5_scrdy0w@mail.gmail.com>
On Mon, Jan 28, 2019 at 3:43 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Tue, Dec 11, 2018 at 9:24 PM Rob Herring <robh@kernel.org> wrote:
> > This adds the build infrastructure for checking DT binding schema
> > documents and validating dts files using the binding schema.
> >
> > Check DT binding schema documents:
> > make dt_binding_check
> >
> > Build dts files and check using DT binding schema:
> > make dtbs_check
> >
> > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> > use for validation. This makes it easier to find and fix errors
> > generated by a specific schema.
> >
> > Currently, the validation targets are separate from a normal build to
> > avoid a hard dependency on the external DT schema project and because
> > there are lots of warnings generated.
> >
> > Cc: Jonathan Corbet <corbet@lwn.net>
> > Cc: Mark Rutland <mark.rutland@arm.com>
> > Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Cc: Michal Marek <michal.lkml@markovi.net>
> > Cc: linux-doc@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Cc: linux-kbuild@vger.kernel.org
> > Signed-off-by: Rob Herring <robh@kernel.org>
>
> BTW, what are the CONFIG dependencies for this to work?
> E.g. defconfig on x86_64 fails, even after enabling CONFIG_OF:
I generally use allmodconfig which enables building all DTs.
Yes, there's a dependency on CONFIG_DTC which isn't always enabled
with CONFIG_OF. Maybe it should be. The only other solutions I've
thought of are either always build dtc or make the targets conditional
on CONFIG_DTC. The latter would only change the error message.
Rob
^ permalink raw reply
* Re: [PATCH 00/11] Refactor exception entry on 40x/6xx/8xx
From: Christophe Leroy @ 2019-01-28 14:56 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20190128141531.GA664@infradead.org>
Le 28/01/2019 à 15:15, Christoph Hellwig a écrit :
> On Mon, Jan 28, 2019 at 11:11:10AM +0000, Christophe Leroy wrote:
>> This serie refactors exception entry macros for 40x, 6xx and 8xx
>>
>> This serie will benefit to the implementation of CONFIG_VMAP, and also
>> to Ben's serie on MSR_EE.
>
> We don't have a CONFIG_VMAP. Do you mean CONFIG_VMAP_STACK ?
>
Yes that's what I mean, sorry.
^ permalink raw reply
* Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
From: Mathias Thore @ 2019-01-28 14:36 UTC (permalink / raw)
To: Christophe Leroy, leoyang.li@nxp.com, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, David Gounaris, Joakim Tjernlund
In-Reply-To: <6bc7e64a-b91a-cb6e-ed65-5e412cef3a76@c-s.fr>
Hi,
This is what we observed: there was a storm on the medium so that our controller could not do its TX, resulting in timeout. When timeout occurs, the driver clears all descriptors from the TX queue. The function called in this patch is used to reflect this clearing also in the BQL layer. Without it, the controller would get stuck, unable to perform TX, even several minutes after the storm had ended. Bringing the device down and then up again would solve the problem, but this patch also solves it automatically.
Some other drivers do the same, for example e1000e driver calls netdev_reset_queue in its e1000_clean_tx_ring function. It is possible that other drivers should do the same; I have no way of verifying this.
Regards,
Mathias
--
From: Christophe Leroy <christophe.leroy@c-s.fr>
Sent: Monday, January 28, 2019 10:48 AM
To: Mathias Thore; leoyang.li@nxp.com; netdev@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; David Gounaris; Joakim Tjernlund
Subject: Re: [PATCH] ucc_geth: Reset BQL queue when stopping device
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi,
Le 28/01/2019 à 10:07, Mathias Thore a écrit :
> After a timeout event caused by for example a broadcast storm, when
> the MAC and PHY are reset, the BQL TX queue needs to be reset as
> well. Otherwise, the device will exhibit severe performance issues
> even after the storm has ended.
What are the symptomns ?
Is this reset needed on any network driver in that case, or is it
something particular for the ucc_geth ?
For instance, the freescale fs_enet doesn't have that reset. Should it
have it too ?
Christophe
>
> Co-authored-by: David Gounaris <david.gounaris@infinera.com>
> Signed-off-by: Mathias Thore <mathias.thore@infinera.com>
> ---
> drivers/net/ethernet/freescale/ucc_geth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/ucc_geth.c b/drivers/net/ethernet/freescale/ucc_geth.c
> index c3d539e209ed..eb3e65e8868f 100644
> --- a/drivers/net/ethernet/freescale/ucc_geth.c
> +++ b/drivers/net/ethernet/freescale/ucc_geth.c
> @@ -1879,6 +1879,8 @@ static void ucc_geth_free_tx(struct ucc_geth_private *ugeth)
> u16 i, j;
> u8 __iomem *bd;
>
> + netdev_reset_queue(ugeth->ndev);
> +
> ug_info = ugeth->ug_info;
> uf_info = &ug_info->uf_info;
>
>
^ permalink raw reply
* Re: [PATCH 00/11] Refactor exception entry on 40x/6xx/8xx
From: Christoph Hellwig @ 2019-01-28 14:15 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <cover.1548673552.git.christophe.leroy@c-s.fr>
On Mon, Jan 28, 2019 at 11:11:10AM +0000, Christophe Leroy wrote:
> This serie refactors exception entry macros for 40x, 6xx and 8xx
>
> This serie will benefit to the implementation of CONFIG_VMAP, and also
> to Ben's serie on MSR_EE.
We don't have a CONFIG_VMAP. Do you mean CONFIG_VMAP_STACK ?
^ permalink raw reply
* Re: [RFC PATCH 2/2] cxl: Force a CAPP reset when unloading CXL module
From: Frederic Barrat @ 2019-01-28 13:34 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev
Cc: Philippe Bergheaud, Alastair D'Silva, Christophe Lombard,
Andrew Donnellan
In-Reply-To: <20190125051131.29351-3-vaibhav@linux.ibm.com>
Le 25/01/2019 à 06:11, Vaibhav Jain a écrit :
> This patch forces shutdown of CAPP when CXL module is unloaded. This
> is accomplished via a call to pnv_phb_to_cxl_mode() with mode ==
> OPAL_PHB_CAPI_MODE_PCIE.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> drivers/misc/cxl/cxl.h | 1 +
> drivers/misc/cxl/main.c | 3 +++
> drivers/misc/cxl/pci.c | 25 ++++++++++++++++++++++++-
> 3 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index d1d927ccb589..e545c2b81faf 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -1136,4 +1136,5 @@ void cxl_context_mm_count_get(struct cxl_context *ctx);
> /* Decrements the reference count to "struct mm_struct" */
> void cxl_context_mm_count_put(struct cxl_context *ctx);
>
> +void cxl_pci_shutdown_capp(void);
> #endif
> diff --git a/drivers/misc/cxl/main.c b/drivers/misc/cxl/main.c
> index f35406be465a..f14ff0dcf231 100644
> --- a/drivers/misc/cxl/main.c
> +++ b/drivers/misc/cxl/main.c
> @@ -372,6 +372,9 @@ static void exit_cxl(void)
> if (cxl_is_power8())
> unregister_cxl_calls(&cxl_calls);
> idr_destroy(&cxl_adapter_idr);
> +
> + if (cpu_has_feature(CPU_FTR_HVMODE))
> + cxl_pci_shutdown_capp();
> }
>
> module_init(init_cxl);
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index c79ba1c699ad..01be2e2d1069 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -25,7 +25,7 @@
>
> #include "cxl.h"
> #include <misc/cxl.h>
> -
> +#include <misc/cxllib.h>
>
> #define CXL_PCI_VSEC_ID 0x1280
> #define CXL_VSEC_MIN_SIZE 0x80
> @@ -2065,6 +2065,29 @@ static void cxl_pci_resume(struct pci_dev *pdev)
> }
> }
>
> +void cxl_pci_shutdown_capp(void)
> +{
> + struct pci_dev *pdev;
> + struct pci_bus *root_bus;
> + int rc;
> +
> + /* Iterate over all CAPP supported PHB's and force them to PCI mode */
> + list_for_each_entry(root_bus, &pci_root_buses, node) {
> + for_each_pci_bridge(pdev, root_bus) {
> +
> + if (!cxllib_slot_is_supported(pdev, 0))
> + continue;
> +
> + rc = pnv_phb_to_cxl_mode(pdev,
> + OPAL_PHB_CAPI_MODE_PCIE);
> + if (rc)
> + dev_err(&pdev->dev,
> + "cxl: Error resetting CAPP. Err=%d\n",
> + rc);
> + }
That's the part I don't like. We're iterating over quite a few PCI
devices, we basically don't know the ones we need to reset.
If we have a per-adapter property on /sys to activate the
reset-on-unload, then we could move the call to
pnv_phb_to_cxl_mode(OPAL_PHB_CAPI_MODE_PCIE) on the cxl_remove()
callback, and only do it for the adapters we've been asked.
Fred
> + }
> +}
> +
> static const struct pci_error_handlers cxl_err_handler = {
> .error_detected = cxl_pci_error_detected,
> .slot_reset = cxl_pci_slot_reset,
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] powerpc/powernv: Add support for CXL mode switch that need PHB reset
From: Frederic Barrat @ 2019-01-28 13:34 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev
Cc: Philippe Bergheaud, Alastair D'Silva, Christophe Lombard,
Andrew Donnellan
In-Reply-To: <20190125051131.29351-2-vaibhav@linux.ibm.com>
Le 25/01/2019 à 06:11, Vaibhav Jain a écrit :
> Recent updates to OPAL [1] have provided support for new CXL modes on
> PHB that need to force a cold reset on the bridge (CRESET). However
> PHB CRESET is a multi step process and cannot be completed
> synchronously as expected by current kernel implementation that issues
> opal call opal_pci_set_phb_cxl_mode().
>
> Hence this patch updates pnv_phb_to_cxl_mode() to implement a polling
> loop that handles specific error codes (OPAL_BUSY) returned from
> opal_pci_set_phb_cxl_mode() and drive the OPAL pci-state machine, if the
> requested CXL mode needs a CRESET.
>
> The patch also updates pnv_phb_to_cxl_mode() to convert and return
> OPAL error codes into kernel error codes. This removes a previous
> issue where callers to this function would have to include
> 'opal-api.h' to check for specific OPAL error codes.
>
> References:
> [1]: https://lists.ozlabs.org/pipermail/skiboot/2019-January/013063.html
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-cxl.c | 71 +++++++++++++++++++++---
> 1 file changed, 63 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-cxl.c b/arch/powerpc/platforms/powernv/pci-cxl.c
> index 1b18111453d7..d33d662c6212 100644
> --- a/arch/powerpc/platforms/powernv/pci-cxl.c
> +++ b/arch/powerpc/platforms/powernv/pci-cxl.c
> @@ -10,6 +10,7 @@
> #include <linux/module.h>
> #include <asm/pnv-pci.h>
> #include <asm/opal.h>
> +#include <linux/delay.h>
>
> #include "pci.h"
>
> @@ -18,21 +19,75 @@ int pnv_phb_to_cxl_mode(struct pci_dev *dev, uint64_t mode)
> struct pci_controller *hose = pci_bus_to_host(dev->bus);
> struct pnv_phb *phb = hose->private_data;
> struct pnv_ioda_pe *pe;
> + unsigned long starttime, endtime;
> int rc;
>
> pe = pnv_ioda_get_pe(dev);
> if (!pe)
> - return -ENODEV;
> + return -ENOENT;
> +
> + pe_info(pe, "Switching PHB to CXL mode=%d\n", mode);
> +
> + /*
> + * Use a 15 second timeout for mode switch. Value arrived after
> + * limited testing and may need more tweaking.
> + */
> + starttime = jiffies;
> + endtime = starttime + HZ * 15;
> +
> + do {
> + rc = opal_pci_set_phb_cxl_mode(phb->opal_id, mode,
> + pe->pe_number);
> +
> + /* Wait until mode transistion done */
> + if (rc != OPAL_BUSY && rc != OPAL_BUSY_EVENT)
> + break;
> +
> + /* Check if we timedout */
> + if (time_after(jiffies, endtime)) {
> + rc = OPAL_TIMEOUT;
> + break;
> + }
>
> - pe_info(pe, "Switching PHB to CXL\n");
> + /* Opal Busy with mode switch. Run pci state-machine */
> + rc = opal_pci_poll(phb->opal_id);
> + if (rc >= 0) {
> + /* wait for some time */
> + if (rc > 0)
> + msleep(rc);
> + opal_poll_events(NULL);
Why is a call to opal_poll_events() needed?
Fred
> + rc = OPAL_BUSY;
> + /* Continue with the mode switch */
> + }
> + } while (rc == OPAL_BUSY || rc == OPAL_BUSY_EVENT);
> +
> + pe_level_printk(pe, KERN_DEBUG, "CXL mode switch finished in %u-msecs.",
> + jiffies_to_msecs(jiffies - starttime));
>
> - rc = opal_pci_set_phb_cxl_mode(phb->opal_id, mode, pe->pe_number);
> - if (rc == OPAL_UNSUPPORTED)
> - dev_err(&dev->dev, "Required cxl mode not supported by firmware - update skiboot\n");
> - else if (rc)
> - dev_err(&dev->dev, "opal_pci_set_phb_cxl_mode failed: %i\n", rc);
> + /* Check OPAL errors and convert them to kernel error codes */
> + switch (rc) {
> + case OPAL_SUCCESS:
> + return 0;
>
> - return rc;
> + case OPAL_PARAMETER:
> + dev_err(&dev->dev, "CXL not supported on this PHB\n");
> + return -ENOENT;
> +
> + case OPAL_UNSUPPORTED:
> + dev_err(&dev->dev,
> + "Required cxl mode not supported by firmware"
> + " - update skiboot\n");
> + return -ENODEV;
> +
> + case OPAL_TIMEOUT:
> + dev_err(&dev->dev, "opal_pci_set_phb_cxl_mode Timedout\n");
> + return -ETIME;
> +
> + default:
> + dev_err(&dev->dev,
> + "opal_pci_set_phb_cxl_mode failed: %i\n", rc);
> + return -EIO;
> + };
> }
> EXPORT_SYMBOL(pnv_phb_to_cxl_mode);
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] cxl: Add support for disabling CAPP when unloading CXL
From: Frederic Barrat @ 2019-01-28 13:34 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev
Cc: Philippe Bergheaud, Alastair D'Silva, Christophe Lombard,
Andrew Donnellan
In-Reply-To: <20190125051131.29351-1-vaibhav@linux.ibm.com>
Hi Vaibhav,
I think there's value in there, as I'm hearing Mellanox would prefer to
start from a "clean" state, as in pci mode, when they load their driver
after a card FW update.
However, I'm pretty reluctant to make it the default behaviour. It's not
like we haven't had our share of problems on reset before :-)
Furthermore, for non-mlx5 case, we don't really have a reason for this.
I'm thinking we could activate it through a per-adapter property, on
/sys. See comment in one of the patches.
Fred
Le 25/01/2019 à 06:11, Vaibhav Jain a écrit :
> Recent updates to OPAL have implemented necessary infrastructure [1] to disable
> CAPP and switch PHB back to PCIE mode during fast reset. This small patch-set
> uses the same OPAL infrastructure to force disable of CAPP when CXL module is
> unloaded via rmmod.
>
> References:
> [1]: https://lists.ozlabs.org/pipermail/skiboot/2019-January/013063.html
>
> Vaibhav Jain (2):
> powerpc/powernv: Add support for CXL mode switch that need PHB reset
> cxl: Force a CAPP reset when unloading CXL module
>
> arch/powerpc/platforms/powernv/pci-cxl.c | 71 +++++++++++++++++++++---
> drivers/misc/cxl/cxl.h | 1 +
> drivers/misc/cxl/main.c | 3 +
> drivers/misc/cxl/pci.c | 25 ++++++++-
> 4 files changed, 91 insertions(+), 9 deletions(-)
>
^ permalink raw reply
* [PATCH v1] PCI/AER: use match_string() helper to simplify the code
From: Andy Shevchenko @ 2019-01-28 11:57 UTC (permalink / raw)
To: Russell Currey, Sam Bobroff, Oliver O'Halloran, linuxppc-dev,
Bjorn Helgaas, linux-pci
Cc: Andy Shevchenko
match_string() returns the index of an array for a matching string,
which can be used intead of open coded implementation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/pci/pcie/aer.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index fed29de783e0..f8fc2114ad39 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -117,7 +117,7 @@ bool pci_aer_available(void)
static int ecrc_policy = ECRC_POLICY_DEFAULT;
-static const char *ecrc_policy_str[] = {
+static const char * const ecrc_policy_str[] = {
[ECRC_POLICY_DEFAULT] = "bios",
[ECRC_POLICY_OFF] = "off",
[ECRC_POLICY_ON] = "on"
@@ -203,11 +203,8 @@ void pcie_ecrc_get_policy(char *str)
{
int i;
- for (i = 0; i < ARRAY_SIZE(ecrc_policy_str); i++)
- if (!strncmp(str, ecrc_policy_str[i],
- strlen(ecrc_policy_str[i])))
- break;
- if (i >= ARRAY_SIZE(ecrc_policy_str))
+ i = match_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str);
+ if (i < 0)
return;
ecrc_policy = i;
--
2.20.1
^ permalink raw reply related
* [PATCH 11/11] powerpc/40x: Refactor exception entry macros by using head_32.h
From: Christophe Leroy @ 2019-01-28 11:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1548673552.git.christophe.leroy@c-s.fr>
Refactor exception entry macros by using the ones defined in head_32.h
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/head_40x.S | 94 ++++--------------------------------------
1 file changed, 8 insertions(+), 86 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index d52e460ea85e..e123bb3aff96 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -44,6 +44,14 @@
#include <asm/export.h>
#include <asm/asm-405.h>
+.macro DO_KVM intno
+.endm
+
+/* clear MSR_WE (necessary?)*/
+#define CLR_MSR_WE(reg) rlwinm reg, reg, 0, ~MSR_WE
+
+#include "head_32.h"
+
/* As with the other PowerPC ports, it is expected that when code
* execution begins here, the following registers contain valid, yet
* optional, information:
@@ -99,52 +107,6 @@ _ENTRY(saved_ksp_limit)
.space 4
/*
- * Exception vector entry code. This code runs with address translation
- * turned off (i.e. using physical addresses). We assume SPRG_THREAD has
- * the physical address of the current task thread_struct.
- */
-#define EXCEPTION_PROLOG \
- mtspr SPRN_SPRG_SCRATCH0,r10; /* save two registers to work with */\
- mtspr SPRN_SPRG_SCRATCH1,r11; \
- mfcr r10; /* save CR in r10 for now */\
- EXCEPTION_PROLOG_1; \
- EXCEPTION_PROLOG_2
-
-#define EXCEPTION_PROLOG_1 \
- mfspr r11,SPRN_SRR1; /* check whether user or kernel */\
- andi. r11,r11,MSR_PR; \
- tophys(r11,r1); \
- beq 1f; \
- mfspr r11,SPRN_SPRG_THREAD; /* if from user, start at top of */\
- lwz r11,TASK_STACK-THREAD(r11); /* this thread's kernel stack */\
- addi r11,r11,THREAD_SIZE; \
- tophys(r11,r11); \
-1: subi r11,r11,INT_FRAME_SIZE; /* Allocate an exception frame */
-
-#define EXCEPTION_PROLOG_2 \
- stw r10,_CCR(r11); /* save various registers */\
- stw r12,GPR12(r11); \
- stw r9,GPR9(r11); \
- mfspr r10,SPRN_SPRG_SCRATCH0; \
- stw r10,GPR10(r11); \
- mfspr r12,SPRN_SPRG_SCRATCH1; \
- stw r12,GPR11(r11); \
- mflr r10; \
- stw r10,_LINK(r11); \
- mfspr r12,SPRN_SRR0; \
- stw r1,GPR1(r11); \
- mfspr r9,SPRN_SRR1; \
- stw r1,0(r11); \
- tovirt(r1,r11); /* set new kernel sp */ \
- rlwinm r9,r9,0,14,12; /* clear MSR_WE (necessary?) */\
- stw r0,GPR0(r11); \
- lis r10, STACK_FRAME_REGS_MARKER@ha; /* exception frame marker */\
- addi r10, r10, STACK_FRAME_REGS_MARKER@l; \
- stw r10, 8(r11); \
- SAVE_4GPRS(3, r11); \
- SAVE_2GPRS(7, r11)
-
-/*
* Exception prolog for critical exceptions. This is a little different
* from the normal exception prolog above since a critical exception
* can potentially occur at any point during normal exception processing.
@@ -205,32 +167,12 @@ _ENTRY(saved_ksp_limit)
/*
* Exception vectors.
*/
-#define START_EXCEPTION(n, label) \
- . = n; \
-label:
-
-#define EXCEPTION(n, label, hdlr, xfer) \
- START_EXCEPTION(n, label); \
- EXCEPTION_PROLOG; \
- addi r3,r1,STACK_FRAME_OVERHEAD; \
- xfer(n, hdlr)
-
#define CRITICAL_EXCEPTION(n, label, hdlr) \
START_EXCEPTION(n, label); \
CRITICAL_EXCEPTION_PROLOG; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
EXC_XFER_TEMPLATE_CRITICAL(hdlr, n+2)
-#define EXC_XFER_TEMPLATE(hdlr, trap, msr, copyee, tfer, ret) \
- li r10,trap; \
- stw r10,_TRAP(r11); \
- lis r10,msr@h; \
- ori r10,r10,msr@l; \
- copyee(r10, r9); \
- bl tfer; \
- .long hdlr; \
- .long ret
-
#define EXC_XFER_TEMPLATE_CRITICAL(hdlr, trap) \
li r10,trap; \
stw r10,_TRAP(r11); \
@@ -239,26 +181,6 @@ label:
.long hdlr; \
.long ret_from_crit_exc
-#define COPY_EE(d, s) rlwimi d,s,0,16,16
-#define NOCOPY(d, s)
-
-#define EXC_XFER_STD(n, hdlr) \
- EXC_XFER_TEMPLATE(hdlr, n, MSR_KERNEL, NOCOPY, transfer_to_handler_full, \
- ret_from_except_full)
-
-#define EXC_XFER_LITE(n, hdlr) \
- EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, NOCOPY, transfer_to_handler, \
- ret_from_except)
-
-#define EXC_XFER_EE(n, hdlr) \
- EXC_XFER_TEMPLATE(hdlr, n, MSR_KERNEL, COPY_EE, transfer_to_handler_full, \
- ret_from_except_full)
-
-#define EXC_XFER_EE_LITE(n, hdlr) \
- EXC_XFER_TEMPLATE(hdlr, n+1, MSR_KERNEL, COPY_EE, transfer_to_handler, \
- ret_from_except)
-
-
/*
* 0x0100 - Critical Interrupt Exception
*/
--
2.13.3
^ permalink raw reply related
* [PATCH 10/11] powerpc/40x: Add EXC_XFER_TEMPLATE_CRITICAL()
From: Christophe Leroy @ 2019-01-28 11:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <cover.1548673552.git.christophe.leroy@c-s.fr>
This patch adds EXC_XFER_TEMPLATE_CRITICAL() for handling
transfer to critical exception handler. This will allow
to move the normal exception to using the standard
EXC_XFER_TEMPLATE() defined in head_32.h
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/kernel/head_40x.S | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 1203075c0c1a..d52e460ea85e 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -219,9 +219,7 @@ label:
START_EXCEPTION(n, label); \
CRITICAL_EXCEPTION_PROLOG; \
addi r3,r1,STACK_FRAME_OVERHEAD; \
- EXC_XFER_TEMPLATE(hdlr, n+2, (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), \
- NOCOPY, crit_transfer_to_handler, \
- ret_from_crit_exc)
+ EXC_XFER_TEMPLATE_CRITICAL(hdlr, n+2)
#define EXC_XFER_TEMPLATE(hdlr, trap, msr, copyee, tfer, ret) \
li r10,trap; \
@@ -233,6 +231,14 @@ label:
.long hdlr; \
.long ret
+#define EXC_XFER_TEMPLATE_CRITICAL(hdlr, trap) \
+ li r10,trap; \
+ stw r10,_TRAP(r11); \
+ li r10, MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE); \
+ bl crit_transfer_to_handler; \
+ .long hdlr; \
+ .long ret_from_crit_exc
+
#define COPY_EE(d, s) rlwimi d,s,0,16,16
#define NOCOPY(d, s)
@@ -733,9 +739,7 @@ label:
/* continue normal handling for a critical exception... */
2: mfspr r4,SPRN_DBSR
addi r3,r1,STACK_FRAME_OVERHEAD
- EXC_XFER_TEMPLATE(DebugException, 0x2002, \
- (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)), \
- NOCOPY, crit_transfer_to_handler, ret_from_crit_exc)
+ EXC_XFER_TEMPLATE_CRITICAL(DebugException, 0x2002)
/* Programmable Interval Timer (PIT) Exception. (from 0x1000) */
Decrementer:
@@ -755,10 +759,7 @@ FITException:
WDTException:
CRITICAL_EXCEPTION_PROLOG;
addi r3,r1,STACK_FRAME_OVERHEAD;
- EXC_XFER_TEMPLATE(WatchdogException, 0x1020+2,
- (MSR_KERNEL & ~(MSR_ME|MSR_DE|MSR_CE)),
- NOCOPY, crit_transfer_to_handler,
- ret_from_crit_exc)
+ EXC_XFER_TEMPLATE_CRITICAL(WatchdogException, 0x1020+2)
/*
* The other Data TLB exceptions bail out to this point
--
2.13.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox