Re: [PATCH 1/2] powerpc/powernv: include asm/smp.h to handle UP config
On Fri, Jun 6, 2014 at 7:33 AM, Anshuman Khandual
khand...@linux.vnet.ibm.com wrote:
On 06/05/2014 08:51 PM, Shreyas B. Prabhu wrote:
Build throws following errors when CONFIG_SMP=n
arch/powerpc/platforms/powernv/setup.c: In function
‘pnv_kexec_wait_secondaries_down’:
arch/powerpc/platforms/powernv/setup.c:179:4: error: implicit declaration of
function ‘get_hard_smp_processor_id’
rc = opal_query_cpu_status(get_hard_smp_processor_id(i),
The usage of get_hard_smp_processor_id() needs the declaration from
asm/smp.h. The file setup.c includes linux/sched.h, which in-turn
includes linux/smp.h. However, linux/smp.h includes asm/smp.h
only on SMP configs and hence UP builds fail.
Fix this by directly including asm/smp.h in setup.c unconditionally.
Can you please clean up the description in the commit message ? and also
the first line in the commit message should mention that the patch is
trying to fix a UP specific build failure.
Both the one-line summary and the first line already mention UP or
CONFIG_SMP=n.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix Failed to find blacklist error on ia64 and ppc64
Ping?
I guess this should go to 3.16 branch, shouldn't it?
(2014/05/30 12:18), Masami Hiramatsu wrote:
On ia64 and ppc64, the function pointer does not point the
entry address of the function, but the address of function
discriptor (which contains the entry address and misc
data.) Since the kprobes passes the function pointer stored
by NOKPROBE_SYMBOL() to kallsyms_lookup_size_offset() for
initalizing its blacklist, it fails and reports many errors
as below.
Failed to find blacklist 000101316830
Failed to find blacklist 0001013000f0a000
Failed to find blacklist 000101315f70a000
Failed to find blacklist 000101324c80a000
Failed to find blacklist 0001013063f0a000
Failed to find blacklist 000101327800a000
Failed to find blacklist 0001013277f0a000
Failed to find blacklist 000101315a70a000
Failed to find blacklist 0001013277e0a000
Failed to find blacklist 000101305a20a000
Failed to find blacklist 0001013277d0a000
Failed to find blacklist 00010130bdc0a000
Failed to find blacklist 00010130dc20a000
Failed to find blacklist 000101309a00a000
Failed to find blacklist 0001013277c0a000
Failed to find blacklist 0001013277b0a000
Failed to find blacklist 0001013277a0a000
Failed to find blacklist 000101327790a000
Failed to find blacklist 000101303140a000
Failed to find blacklist 0001013a3280a000
To fix this bug, this introduces function_entry() macro to
retrieve the entry address from the given function pointer,
and uses for kallsyms_lookup_size_offset() while initializing
blacklist.
Changes in v3:
- Fix a bug to get blacklist address based on function entry
instead of function descriptor. (Suzuki's work, Thanks!)
Changes in V2:
- Use function_entry() macro when lookin up symbols instead
of storing it.
- Update for the latest -next.
Signed-off-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Signed-off-by: Suzuki K. Poulose suz...@in.ibm.com
Reported-by: Tony Luck tony.l...@gmail.com
Cc: Suzuki K. Poulose suz...@in.ibm.com
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com
Cc: Kevin Hao haoke...@gmail.com
Cc: linux-i...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/ia64/include/asm/types.h|2 ++
arch/powerpc/include/asm/types.h | 11 +++
include/linux/types.h|4
kernel/kprobes.c | 11 +++
4 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
index 4c351b1..95279dd 100644
--- a/arch/ia64/include/asm/types.h
+++ b/arch/ia64/include/asm/types.h
@@ -27,5 +27,7 @@ struct fnptr {
unsigned long gp;
};
+#define function_entry(fn) (((struct fnptr *)(fn))-ip)
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_IA64_TYPES_H */
diff --git a/arch/powerpc/include/asm/types.h
b/arch/powerpc/include/asm/types.h
index bfb6ded..8b89d65 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -25,6 +25,17 @@ typedef struct {
unsigned long env;
} func_descr_t;
+#if defined(CONFIG_PPC64) (!defined(_CALL_ELF) || _CALL_ELF == 1)
+/*
+ * On PPC64 ABIv1 the function pointer actually points to the
+ * function's descriptor. The first entry in the descriptor is the
+ * address of the function text.
+ */
+#define function_entry(fn) (((func_descr_t *)(fn))-entry)
+#else
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/linux/types.h b/include/linux/types.h
index a0bb704..3b95369 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -213,5 +213,9 @@ struct callback_head {
};
#define rcu_head callback_head
+#ifndef function_entry
+#define function_entry(fn) ((unsigned long)(fn))
+#endif
+
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_TYPES_H */
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 2ac9f13..3f2d6d4 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -32,6 +32,7 @@
* prasa...@in.ibm.com added function-return probes.
*/
#include linux/kprobes.h
+#include linux/types.h
#include linux/hash.h
#include linux/init.h
#include linux/slab.h
@@ -2042,16 +2043,18 @@ static int __init populate_kprobe_blacklist(unsigned
long *start,
unsigned long offset = 0, size = 0;
for (iter = start; iter end; iter++) {
- if (!kallsyms_lookup_size_offset(*iter, size, offset)) {
- pr_err(Failed to find blacklist %p\n, (void *)*iter);
+ unsigned long entry = function_entry(*iter);
+ if (!kallsyms_lookup_size_offset(entry, size, offset)) {
+ pr_err(Failed to find
[PATCH 1/3 v3] powerpc/fsl-booke: Add support for T2080/T2081 SoC
The T2080 QorIQ multicore processor combines four dual-threaded e6500 Power
Architecture processor cores with high-performance datapath acceleration
logic and network and peripheral bus interfaces required for networking,
telecom/datacom, wireless infrastructure, and mil/aerospace applications.
The T2080 SoC includes the following function and features:
- Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- 16 SerDes lanes up to 10.3125 GHz
- 8 Ethernet interfaces (multiple 1G/2.5G/10G MACs)
- High-speed peripheral interfaces
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0)
- Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz
- Additional peripheral interfaces
- Two serial ATA (SATA 2.0) controllers
- Two high-speed USB 2.0 controllers with integrated PHY
- Enhanced secure digital host controller (SD/SDXC/eMMC)
- Enhanced serial peripheral interface (eSPI)
- Four I2C controllers
- Four 2-pin UARTs or two 4-pin UARTs
- Integrated Flash Controller supporting NAND and NOR flash
- Three eight-channel DMA engines
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0
T2081 is a reduced personality of T2080 with following difference:
Feature T2080 T2081
1G Ethernet numbers: 8 6
10G Ethernet numbers: 4 2
SerDes lanes: 168
Serial RapidIO,RMan: 2 no
SATA Controller: 2 no
Aurora: yes no
SoC Package: 896-pins 780-pins
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: added pamu node and updated clockgen.
v2: updated with some comments.
arch/powerpc/boot/dts/fsl/t2080si-post.dtsi | 69 +
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 434
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 91 ++
arch/powerpc/include/asm/mpc85xx.h | 2 +
4 files changed, 596 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
new file mode 100644
index 000..082ec20
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
@@ -0,0 +1,69 @@
+/*
+ * T2080 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ t2081si-post.dtsi
+
+soc {
+/include/ qoriq-sata2-0.dtsi
+ sata@22 {
+ fsl,iommu-parent = pamu1;
+ fsl,liodn-reg = guts 0x550; /* SATA1LIODNR */
+ };
+
+/include/ qoriq-sata2-1.dtsi
+ sata@221000 {
+ fsl,iommu-parent = pamu1;
+ fsl,liodn-reg = guts 0x554; /* SATA2LIODNR */
+ };
+};
+
+rio {
+ compatible = fsl,srio;
+ interrupts = 16 2 1 11;
+ #address-cells = 2;
+ #size-cells = 2;
+
[PATCH 2/3 v3] powerpc/fsl-booke: Add initial T208x QDS board support
Add support for Freescale T2080/T2081 QDS Development System Board.
The T2080QDS Development System is a high-performance computing,
evaluation, and development platform that supports T2080 QorIQ
Power Architecture processor, with following major features:
T2080QDS feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LP
- Dual DIMM slots up 2133MT/s with ECC
Ethernet interfaces:
- Two 1Gbps RGMII on-board ports
- Four 10Gbps XFI on-board cages
- 1Gbps/2.5Gbps SGMII Riser card
- 10Gbps XAUI Riser card
Accelerator:
- DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
SerDes:
- 16 lanes up to 10.3125GHz
- Supports Aurora debug, PEX, SATA, SGMII, sRIO, HiGig, XFI and XAUI
IFC:
- 128MB NOR Flash, 512MB NAND Flash, PromJet debug port and FPGA
eSPI:
- Three SPI flash (16MB N25Q128A + 8MB EN25S64 + 512KB SST25WF040)
USB:
- Two USB2.0 ports with internal PHY (one Type-A + one micro Type-AB)
PCIE:
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0, SR-IOV)
SATA:
- Two SATA 2.0 ports on-board
SRIO:
- Two Serial RapidIO 2.0 ports up to 5 GHz
eSDHC:
- Supports SD/MMC/eMMC Card
DMA:
- Three 8-channels DMA controllers
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
System Logic:
- QIXIS-II FPGA system controll
T2081QDS board shares the same PCB with T1040QDS with some differences.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: no change.
v2: updated with some comments.
arch/powerpc/boot/dts/t2080qds.dts| 57 ++
arch/powerpc/boot/dts/t2081qds.dts| 46 +
arch/powerpc/boot/dts/t208xqds.dtsi | 239 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 4 +
5 files changed, 347 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/boot/dts/t2080qds.dts
create mode 100644 arch/powerpc/boot/dts/t2081qds.dts
create mode 100644 arch/powerpc/boot/dts/t208xqds.dtsi
diff --git a/arch/powerpc/boot/dts/t2080qds.dts
b/arch/powerpc/boot/dts/t2080qds.dts
new file mode 100644
index 000..aa1d6d8
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2080qds.dts
@@ -0,0 +1,57 @@
+/*
+ * T2080QDS Device Tree Source
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ fsl/t208xsi-pre.dtsi
+/include/ t208xqds.dtsi
+
+/ {
+ model = fsl,T2080QDS;
+ compatible = fsl,T2080QDS;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ rio: rapidio@ffe0c {
+ reg = 0xf 0xfe0c 0 0x11000;
+
+ port1 {
+ ranges = 0 0 0xc 0x2000 0 0x1000;
+ };
+ port2 {
+ ranges = 0 0 0xc 0x3000 0 0x1000;
+ };
+ };
+};
+
+/include/ fsl/t2080si-post.dtsi
diff --git a/arch/powerpc/boot/dts/t2081qds.dts
b/arch/powerpc/boot/dts/t2081qds.dts
new file mode 100644
index 000..8ec80a7
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2081qds.dts
@@ -0,0 +1,46 @@
+/*
+ * T2081QDS Device Tree Source
+ *
+ * Copyright
[PATCH 3/3 v3] powerpc/t2080rdb: Add T2080RDB board support
T2080PCIe-RDB is a Freescale Reference Design Board that hosts T2080 SoC.
The board feature overview:
Processor:
- T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
DDR Memory:
- Single memory controller capable of supporting DDR3 and DDR3-LP devices
- 72bit 4GB DDR3-LP SODIMM in slot
Ethernet interfaces:
- Two 1Gbps RGMII ports on-board
- Two 10Gbps SFP+ ports on-board
- Two 10Gbps Base-T ports on-board
Accelerator:
- DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
SerDes 16 lanes configuration:
- SerDes-1 Lane A-B: to two 10G SFP+ (MAC9 MAC10)
- SerDes-1 Lane C-D: to two 10G Base-T (MAC1 MAC2)
- SerDes-1 Lane E-H: to PCIe slot (PEX4 Gen3 x4)
- SerDes-2 Lane A-D: to PCIe finger (PEX1 x4)
- SerDes-2 Lane E-F: to C293 secure co-processor (PEX2 x2)
- SerDes-2 Lane G-H: to SATA1 SATA2
IFC/Local Bus
- NOR: 128MB 16-bit NOR flash
- NAND: 1GB 8-bit NAND flash
- CPLD: for system controlling with programable header on-board
eSPI:
- 64MB N25Q512 SPI flash
USB:
- Two USB2.0 ports with internal PHY (both Type-A)
PCIe:
- One PCIe x4 goldfinger
- One PCIe x4 slot
- One PCIe x2 end-point device (C293 crypto co-processor)
SATA:
- Two SATA 2.0 ports on-board
SDHC:
- support a MicroSD/TF card on-board
I2C:
- Four I2C controllers.
UART:
- Dual 4-pins UART serial ports
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: no change.
v2: updated with some comments.
arch/powerpc/boot/dts/t2080rdb.dts| 57
arch/powerpc/boot/dts/t208xrdb.dtsi | 197 ++
arch/powerpc/platforms/85xx/Kconfig | 2 +-
arch/powerpc/platforms/85xx/corenet_generic.c | 2 +
4 files changed, 257 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/boot/dts/t2080rdb.dts
create mode 100644 arch/powerpc/boot/dts/t208xrdb.dtsi
diff --git a/arch/powerpc/boot/dts/t2080rdb.dts
b/arch/powerpc/boot/dts/t2080rdb.dts
new file mode 100644
index 000..e889104
--- /dev/null
+++ b/arch/powerpc/boot/dts/t2080rdb.dts
@@ -0,0 +1,57 @@
+/*
+ * T2080PCIe-RDB Board Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ fsl/t208xsi-pre.dtsi
+/include/ t208xrdb.dtsi
+
+/ {
+ model = fsl,T2080RDB;
+ compatible = fsl,T2080RDB;
+ #address-cells = 2;
+ #size-cells = 2;
+ interrupt-parent = mpic;
+
+ rio: rapidio@ffe0c {
+ reg = 0xf 0xfe0c 0 0x11000;
+
+ port1 {
+ ranges = 0 0 0xc 0x2000 0 0x1000;
+ };
+ port2 {
+ ranges = 0 0 0xc 0x3000 0 0x1000;
+ };
+ };
+};
+
+/include/ fsl/t2080si-post.dtsi
diff --git a/arch/powerpc/boot/dts/t208xrdb.dtsi
b/arch/powerpc/boot/dts/t208xrdb.dtsi
new file mode 100644
index 000..3b85985
--- /dev/null
+++ b/arch/powerpc/boot/dts/t208xrdb.dtsi
@@ -0,0 +1,197 @@
+/*
+ * T2080PCIe-RDB Board Device Tree Source
+ *
+ * Copyright 2014 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of
[PATCH 4/6] powerpc/powernv: Add @it_owner to iommu_table struct
Modern IBM POWERPC systems support multiple IOMMU tables per PHB
so we need a more reliable way (compared to container_of()) to get
a PE pointer from the iommu_table struct pointer used in IOMMU functions.
This also provides better way of getting a PE handle from iommu_table
pointer.
This defines an empty iommu_owner struct. This adds it to pnv_ioda_pe
struct and replaces container_of(tbl) with container_of(tbl-it_owner).
This adds an @owner parameter to pnv_pci_setup_iommu_table().
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 6 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 18 +++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c| 7 +--
arch/powerpc/platforms/powernv/pci.h| 4 +++-
5 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 42632c7..f503a5c 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -60,6 +60,11 @@ struct iommu_pool {
spinlock_t lock;
} cacheline_aligned_in_smp;
+/* This is to use with container_of() */
+struct iommu_owner {
+ unsigned char __unused[0];
+};
+
struct iommu_table {
unsigned long it_busno; /* Bus number this table belongs to */
unsigned long it_size; /* Size of iommu table in entries */
@@ -78,6 +83,7 @@ struct iommu_table {
struct iommu_group *it_group;
#endif
void (*set_bypass)(struct iommu_table *tbl, bool enable);
+ struct iommu_owner *it_owner;
};
/* Pure 2^n version of get_order */
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 29294b1..1f307ef 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -586,8 +586,8 @@ static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe
*pe,
void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm)
{
- struct pnv_ioda_pe *pe = container_of(tbl, struct pnv_ioda_pe,
- tce32_table);
+ struct pnv_ioda_pe *pe = container_of(tbl-it_owner, struct pnv_ioda_pe,
+ owner);
struct pnv_phb *phb = pe-phb;
if (phb-type == PNV_PHB_IODA1)
@@ -655,7 +655,8 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
/* Setup linux iommu table */
tbl = pe-tce32_table;
pnv_pci_setup_iommu_table(tbl, addr, TCE32_TABLE_SIZE * segs,
- base 28, IOMMU_PAGE_SHIFT_4K);
+ base 28, IOMMU_PAGE_SHIFT_4K,
+ pe-owner);
/* OPAL variant of P7IOC SW invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
@@ -691,11 +692,14 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
static void pnv_pci_ioda2_set_bypass(struct iommu_table *tbl, bool enable)
{
- struct pnv_ioda_pe *pe = container_of(tbl, struct pnv_ioda_pe,
- tce32_table);
- uint16_t window_id = (pe-pe_number 1 ) + 1;
+ struct pnv_ioda_pe *pe;
+ uint16_t window_id;
int64_t rc;
+ BUG_ON(!tbl-it_owner);
+ pe = container_of(tbl-it_owner, struct pnv_ioda_pe, owner);
+ window_id = (pe-pe_number 1) + 1;
+
pe_info(pe, %sabling 64-bit DMA bypass\n, enable ? En : Dis);
if (enable) {
phys_addr_t top = memblock_end_of_DRAM();
@@ -786,7 +790,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
/* Setup linux iommu table */
tbl = pe-tce32_table;
pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- IOMMU_PAGE_SHIFT_4K);
+ IOMMU_PAGE_SHIFT_4K, pe-owner);
/* OPAL variant of PHB3 invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index 94ce348..cf02c14 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -173,7 +173,7 @@ static void __init pnv_pci_init_p5ioc2_phb(struct
device_node *np, u64 hub_id,
phb-dma_dev_setup = pnv_pci_p5ioc2_dma_dev_setup;
pnv_pci_setup_iommu_table(phb-p5ioc2.iommu_table,
tce_mem, tce_size, 0,
- IOMMU_PAGE_SHIFT_4K);
+ IOMMU_PAGE_SHIFT_4K, NULL);
}
void __init pnv_pci_init_p5ioc2_hub(struct device_node *np)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 92d6f5b..aa88c94 100644
---
[PATCH 0/6] powerpc/powernv: Applying it_page_shift to platform code
Here is what I got for powernv in order to support variable page size in iommu_table. I am very uncertain about Patch #4 Add @it_owner to iommu_table struct and wonder if there any better way to get PE from iommu_table. Please comment. Thanks. Alexey Kardashevskiy (6): powerpc/powernv: use it_page_shift for TCE invalidation powerpc/powernv: use it_page_shift in TCE build powerpc/powernv: Add a page size parameter to pnv_pci_setup_iommu_table() powerpc/powernv: Add @it_owner to iommu_table struct powerpc/powernv: Make set_bypass() callback a type powerpc/powernv: Make invalidate() callback an iommu_table callback arch/powerpc/include/asm/iommu.h| 13 ++- arch/powerpc/platforms/powernv/pci-ioda.c | 55 ++--- arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 +- arch/powerpc/platforms/powernv/pci.c| 43 +++--- arch/powerpc/platforms/powernv/pci.h| 7 ++-- 5 files changed, 74 insertions(+), 47 deletions(-) -- 2.0.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/6] powerpc/powernv: Add a page size parameter to pnv_pci_setup_iommu_table()
Since a TCE page size can be other than 4K, make it configurable for
P5IOC2 and IODA PHBs.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 5 +++--
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 ++-
arch/powerpc/platforms/powernv/pci.c| 6 +++---
arch/powerpc/platforms/powernv/pci.h| 2 +-
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 8307fe5..29294b1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -655,7 +655,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
/* Setup linux iommu table */
tbl = pe-tce32_table;
pnv_pci_setup_iommu_table(tbl, addr, TCE32_TABLE_SIZE * segs,
- base 28);
+ base 28, IOMMU_PAGE_SHIFT_4K);
/* OPAL variant of P7IOC SW invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
@@ -785,7 +785,8 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
/* Setup linux iommu table */
tbl = pe-tce32_table;
- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0);
+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
+ IOMMU_PAGE_SHIFT_4K);
/* OPAL variant of PHB3 invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index e3807d6..94ce348 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++ b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
@@ -172,7 +172,8 @@ static void __init pnv_pci_init_p5ioc2_phb(struct
device_node *np, u64 hub_id,
/* Setup TCEs */
phb-dma_dev_setup = pnv_pci_p5ioc2_dma_dev_setup;
pnv_pci_setup_iommu_table(phb-p5ioc2.iommu_table,
- tce_mem, tce_size, 0);
+ tce_mem, tce_size, 0,
+ IOMMU_PAGE_SHIFT_4K);
}
void __init pnv_pci_init_p5ioc2_hub(struct device_node *np)
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index 9f7c556..92d6f5b 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -591,11 +591,11 @@ static void pnv_tce_free_rm(struct iommu_table *tbl, long
index, long npages)
void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
void *tce_mem, u64 tce_size,
- u64 dma_offset)
+ u64 dma_offset, unsigned page_shift)
{
tbl-it_blocksize = 16;
tbl-it_base = (unsigned long)tce_mem;
- tbl-it_page_shift = IOMMU_PAGE_SHIFT_4K;
+ tbl-it_page_shift = page_shift;
tbl-it_offset = dma_offset tbl-it_page_shift;
tbl-it_index = 0;
tbl-it_size = tce_size 3;
@@ -620,7 +620,7 @@ static struct iommu_table *pnv_pci_setup_bml_iommu(struct
pci_controller *hose)
if (WARN_ON(!tbl))
return NULL;
pnv_pci_setup_iommu_table(tbl, __va(be64_to_cpup(basep)),
- be32_to_cpup(sizep), 0);
+ be32_to_cpup(sizep), 0, IOMMU_PAGE_SHIFT_4K);
iommu_init_table(tbl, hose-node);
iommu_register_group(tbl, pci_domain_nr(hose-bus), 0);
diff --git a/arch/powerpc/platforms/powernv/pci.h
b/arch/powerpc/platforms/powernv/pci.h
index cde1694..ca62444 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -199,7 +199,7 @@ int pnv_pci_cfg_write(struct device_node *dn,
int where, int size, u32 val);
extern void pnv_pci_setup_iommu_table(struct iommu_table *tbl,
void *tce_mem, u64 tce_size,
- u64 dma_offset);
+ u64 dma_offset, unsigned page_shift);
extern void pnv_pci_init_p5ioc2_hub(struct device_node *np);
extern void pnv_pci_init_ioda_hub(struct device_node *np);
extern void pnv_pci_init_ioda2_phb(struct device_node *np);
--
2.0.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/6] powerpc/powernv: use it_page_shift for TCE invalidation
This fixes IODA1/2 to use it_page_shift as it may be bigger than 4K.
This changes involved constant values to use ull modifier.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 98824aa..8307fe5 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -512,15 +512,16 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
(__be64 __iomem *)pe-tce_inval_reg_phys :
(__be64 __iomem *)tbl-it_index;
unsigned long start, end, inc;
+ const unsigned shift = tbl-it_page_shift;
start = __pa(startp);
end = __pa(endp);
/* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
if (tbl-it_busno) {
- start = 12;
- end = 12;
- inc = 128 12;
+ start = shift;
+ end = shift;
+ inc = 128ull shift;
start |= tbl-it_busno;
end |= tbl-it_busno;
} else if (tbl-it_type TCE_PCI_SWINV_PAIR) {
@@ -558,18 +559,19 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
(__be64 __iomem *)tbl-it_index;
+ const unsigned shift = tbl-it_page_shift;
/* We'll invalidate DMA address in PE scope */
- start = 0x2ul 60;
+ start = 0x2ull 60;
start |= (pe-pe_number 0xFF);
end = start;
/* Figure out the start, end and step */
inc = tbl-it_offset + (((u64)startp - tbl-it_base) / sizeof(u64));
- start |= (inc 12);
+ start |= (inc shift);
inc = tbl-it_offset + (((u64)endp - tbl-it_base) / sizeof(u64));
- end |= (inc 12);
- inc = (0x1ul 12);
+ end |= (inc shift);
+ inc = (0x1ull shift);
mb();
while (start = end) {
--
2.0.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/6] powerpc/powernv: use it_page_shift in TCE build
This makes use of iommu_table::it_page_shift instead of TCE_SHIFT and TCE_RPN_SHIFT hardcoded values. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru --- arch/powerpc/platforms/powernv/pci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c index 8518817..9f7c556 100644 --- a/arch/powerpc/platforms/powernv/pci.c +++ b/arch/powerpc/platforms/powernv/pci.c @@ -527,10 +527,11 @@ static int pnv_tce_build(struct iommu_table *tbl, long index, long npages, proto_tce |= TCE_PCI_WRITE; tces = tcep = ((__be64 *)tbl-it_base) + index - tbl-it_offset; - rpn = __pa(uaddr) TCE_SHIFT; + rpn = __pa(uaddr) tbl-it_page_shift; while (npages--) - *(tcep++) = cpu_to_be64(proto_tce | (rpn++ TCE_RPN_SHIFT)); + *(tcep++) = cpu_to_be64(proto_tce | + (rpn++ tbl-it_page_shift)); /* Some implementations won't cache invalid TCEs and thus may not * need that flush. We'll probably turn it_type into a bit mask -- 2.0.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/6] powerpc/powernv: Make invalidate() callback an iommu_table callback
This implements pnv_pci_ioda(1|2)_tce_invalidate as a callback
of iommu_table to simplify code structure.
This registers invalidate() callbacks for IODA1 and IODA2.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 4
arch/powerpc/platforms/powernv/pci-ioda.c | 28
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c| 33 -
arch/powerpc/platforms/powernv/pci.h| 5 ++---
5 files changed, 39 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 2bc8f8c..5326030 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -66,6 +66,9 @@ struct iommu_owner {
};
typedef void (*iommu_set_bypass_fn)(struct iommu_table *tbl, bool enable);
+typedef void (*iommu_invalidate_fn)(struct iommu_table *tbl,
+ __be64 *startp, __be64 *endp, bool rm);
+
struct iommu_table {
unsigned long it_busno; /* Bus number this table belongs to */
unsigned long it_size; /* Size of iommu table in entries */
@@ -84,6 +87,7 @@ struct iommu_table {
struct iommu_group *it_group;
#endif
iommu_set_bypass_fn set_bypass;
+ iommu_invalidate_fn invalidate;
struct iommu_owner *it_owner;
};
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1f307ef..ca09457 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -504,10 +504,11 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe, struct pci_bus *bus)
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_owner, struct pnv_ioda_pe,
+ owner);
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
(__be64 __iomem *)tbl-it_index;
@@ -551,10 +552,11 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
*/
}
-static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_owner, struct pnv_ioda_pe,
+ owner);
unsigned long start, end, inc;
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
@@ -583,19 +585,6 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
}
}
-void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
-{
- struct pnv_ioda_pe *pe = container_of(tbl-it_owner, struct pnv_ioda_pe,
- owner);
- struct pnv_phb *phb = pe-phb;
-
- if (phb-type == PNV_PHB_IODA1)
- pnv_pci_ioda1_tce_invalidate(pe, tbl, startp, endp, rm);
- else
- pnv_pci_ioda2_tce_invalidate(pe, tbl, startp, endp, rm);
-}
-
static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe, unsigned int base,
unsigned int segs)
@@ -656,7 +645,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
tbl = pe-tce32_table;
pnv_pci_setup_iommu_table(tbl, addr, TCE32_TABLE_SIZE * segs,
base 28, IOMMU_PAGE_SHIFT_4K,
- pe-owner);
+ pe-owner, pnv_pci_ioda1_tce_invalidate);
/* OPAL variant of P7IOC SW invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
@@ -790,7 +779,8 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
/* Setup linux iommu table */
tbl = pe-tce32_table;
pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- IOMMU_PAGE_SHIFT_4K, pe-owner);
+ IOMMU_PAGE_SHIFT_4K, pe-owner,
+ pnv_pci_ioda2_tce_invalidate);
/* OPAL variant of PHB3 invalidated TCEs */
swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
diff --git a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
b/arch/powerpc/platforms/powernv/pci-p5ioc2.c
index cf02c14..ea80ef7 100644
--- a/arch/powerpc/platforms/powernv/pci-p5ioc2.c
+++
[PATCH 5/6] powerpc/powernv: Make set_bypass() callback a type
There are going to be other callbacks which are going to be used as
function parameters so change the existing set_bypass() callback to be
a type.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index f503a5c..2bc8f8c 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -65,6 +65,7 @@ struct iommu_owner {
unsigned char __unused[0];
};
+typedef void (*iommu_set_bypass_fn)(struct iommu_table *tbl, bool enable);
struct iommu_table {
unsigned long it_busno; /* Bus number this table belongs to */
unsigned long it_size; /* Size of iommu table in entries */
@@ -82,7 +83,7 @@ struct iommu_table {
#ifdef CONFIG_IOMMU_API
struct iommu_group *it_group;
#endif
- void (*set_bypass)(struct iommu_table *tbl, bool enable);
+ iommu_set_bypass_fn set_bypass;
struct iommu_owner *it_owner;
};
--
2.0.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] KVM: PPC: BOOK3S: PR: Doorbell support
Alexander Graf ag...@suse.de writes:
On 05.06.14 14:08, Aneesh Kumar K.V wrote:
We don't have SMT support yet, hence we should not find a doorbell
message generated
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_emulate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_emulate.c
b/arch/powerpc/kvm/book3s_emulate.c
index 1bb16a59dcbc..d6c87d085182 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -28,7 +28,9 @@
#define OP_19_XOP_RFI 50
#define OP_31_XOP_MFMSR83
+#define OP_31_XOP_MSGSNDP 142
#define OP_31_XOP_MTMSR146
+#define OP_31_XOP_MSGCLRP 174
#define OP_31_XOP_MTMSRD 178
#define OP_31_XOP_MTSR 210
#define OP_31_XOP_MTSRIN 242
@@ -303,6 +305,22 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run,
struct kvm_vcpu *vcpu,
break;
}
+case OP_31_XOP_MSGSNDP:
+{
+/*
+ * PR KVM still don't support SMT mode. So we should
still?
+ * not see a MSGSNDP/MSGCLRP used with PR KVM
+ */
+pr_info(KVM: MSGSNDP used in non SMT case\n);
+emulated = EMULATE_FAIL;
What would happen on an HV guest with only 1 thread that MSGSNDs to
thread 0? Would the guest get an illegal instruction trap, a
self-interrupt or would this be a simple nop?
We do get a self-interrupt. I tried the below
tag = mfspr(SPRN_TIR) 0x7f;
ppc_msgsnd(5, 0, tag);
And that results in doorbell exception. That implies we will have to
have full implementation of doorbell. You can drop patch 2 and 3 from
this series. I will rework them.
NOTE: This is not an issue for Linux guest, because we don't send ipi
to self. But to complete the emulation of msgsndp we will need to
emulate it properly.
-aneesh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 1/2] powerpc/powernv: include asm/smp.h to fix UP build failure
Build throws following errors when CONFIG_SMP=n arch/powerpc/platforms/powernv/setup.c: In function ‘pnv_kexec_wait_secondaries_down’: arch/powerpc/platforms/powernv/setup.c:179:4: error: implicit declaration of function ‘get_hard_smp_processor_id’ rc = opal_query_cpu_status(get_hard_smp_processor_id(i), The usage of get_hard_smp_processor_id() needs the declaration from asm/smp.h. The file setup.c includes linux/sched.h, which in-turn includes linux/smp.h. However, linux/smp.h includes asm/smp.h only on SMP configs and hence UP builds fail. Fix this by directly including asm/smp.h in setup.c unconditionally. Reported-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- Changes is v2: Commit message improved based on suggestion. arch/powerpc/platforms/powernv/setup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c index 8c16a5f..678573c 100644 --- a/arch/powerpc/platforms/powernv/setup.c +++ b/arch/powerpc/platforms/powernv/setup.c @@ -35,6 +35,7 @@ #include asm/rtas.h #include asm/opal.h #include asm/kexec.h +#include asm/smp.h #include powernv.h -- 1.9.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 2/2] powerpc/powernv : Disable subcore for UP configs
Build throws following errors when CONFIG_SMP=n arch/powerpc/platforms/powernv/subcore.c: In function ‘cpu_update_split_mode’: arch/powerpc/platforms/powernv/subcore.c:274:15: error: ‘setup_max_cpus’ undeclared (first use in this function) arch/powerpc/platforms/powernv/subcore.c:285:5: error: lvalue required as left operand of assignment 'setup_max_cpus' variable is relevant only on SMP, so there is no point working around it for UP. Furthermore, subcore itself is relevant only on SMP and hence the better solution is to exclude subcore.o and subcore-asm.o for UP builds. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com --- Changes in v2: Excluding subcore-asm.o which is part of the subcore feature for UP configs. arch/powerpc/platforms/powernv/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile index 4ad0d34..d55891f 100644 --- a/arch/powerpc/platforms/powernv/Makefile +++ b/arch/powerpc/platforms/powernv/Makefile @@ -1,9 +1,9 @@ obj-y += setup.o opal-takeover.o opal-wrappers.o opal.o opal-async.o obj-y += 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 subcore.o subcore-asm.o +obj-y += opal-msglog.o -obj-$(CONFIG_SMP) += smp.o +obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o obj-$(CONFIG_EEH) += eeh-ioda.o eeh-powernv.o obj-$(CONFIG_PPC_SCOM) += opal-xscom.o -- 1.9.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: KVM: PPC: BOOK3S: PR: P8 Support
On 05.06.14 14:08, Aneesh Kumar K.V wrote: This patchset adds support for emulating VTB, IC and Doorbell features in P8. Doorbell support is dummy since we don't support SMT cores with PR-KVM. Thanks, applied patches 1 and 4 to kvm-ppc-queue. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/powernv : Disable subcore for UP configs
On 06/06/2014 03:52 PM, Shreyas B. Prabhu wrote: Build throws following errors when CONFIG_SMP=n arch/powerpc/platforms/powernv/subcore.c: In function ‘cpu_update_split_mode’: arch/powerpc/platforms/powernv/subcore.c:274:15: error: ‘setup_max_cpus’ undeclared (first use in this function) arch/powerpc/platforms/powernv/subcore.c:285:5: error: lvalue required as left operand of assignment 'setup_max_cpus' variable is relevant only on SMP, so there is no point working around it for UP. Furthermore, subcore itself is relevant only on SMP and hence the better solution is to exclude subcore.o and subcore-asm.o for UP builds. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Regards, Srivatsa S. Bhat --- Changes in v2: Excluding subcore-asm.o which is part of the subcore feature for UP configs. arch/powerpc/platforms/powernv/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile index 4ad0d34..d55891f 100644 --- a/arch/powerpc/platforms/powernv/Makefile +++ b/arch/powerpc/platforms/powernv/Makefile @@ -1,9 +1,9 @@ obj-y+= setup.o opal-takeover.o opal-wrappers.o opal.o opal-async.o obj-y+= 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 subcore.o subcore-asm.o +obj-y+= opal-msglog.o -obj-$(CONFIG_SMP)+= smp.o +obj-$(CONFIG_SMP)+= smp.o subcore.o subcore-asm.o obj-$(CONFIG_PCI)+= pci.o pci-p5ioc2.o pci-ioda.o obj-$(CONFIG_EEH)+= eeh-ioda.o eeh-powernv.o obj-$(CONFIG_PPC_SCOM) += opal-xscom.o ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
On 05.06.14 14:08, Aneesh Kumar K.V wrote: virtual time base register is a per VM, per cpu register that needs to be saved and restored on vm exit and entry. Writing to VTB is not allowed in the privileged mode. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com For some reason BUG() doesn't always trigger the execution stops here logic in gcc. So I've squashed this patch into yours. Alex diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 3e7085d..99de6ad 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1206,6 +1206,7 @@ static inline unsigned long mfvtb (void) * capture that. */ BUG(); +return 0; } #ifdef __powerpc64__ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/powernv: include asm/smp.h to handle UP config
On Fri, 2014-06-06 at 11:03 +0530, Anshuman Khandual wrote: On 06/05/2014 08:51 PM, Shreyas B. Prabhu wrote: Build throws following errors when CONFIG_SMP=n arch/powerpc/platforms/powernv/setup.c: In function ‘pnv_kexec_wait_secondaries_down’: arch/powerpc/platforms/powernv/setup.c:179:4: error: implicit declaration of function ‘get_hard_smp_processor_id’ rc = opal_query_cpu_status(get_hard_smp_processor_id(i), The usage of get_hard_smp_processor_id() needs the declaration from asm/smp.h. The file setup.c includes linux/sched.h, which in-turn includes linux/smp.h. However, linux/smp.h includes asm/smp.h only on SMP configs and hence UP builds fail. Fix this by directly including asm/smp.h in setup.c unconditionally. Can you please clean up the description in the commit message ? and also the first line in the commit message should mention that the patch is trying to fix a UP specific build failure. I don't understand your comment ... the description and subject line are perfectly fine... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3 v3] powerpc/fsl-booke: Add support for T2080/T2081 SoC
On 06/06/2014 10:18 AM, Shengzhou Liu wrote:
The T2080 QorIQ multicore processor combines four dual-threaded e6500 Power
Architecture processor cores with high-performance datapath acceleration
logic and network and peripheral bus interfaces required for networking,
telecom/datacom, wireless infrastructure, and mil/aerospace applications.
The T2080 SoC includes the following function and features:
- Four dual-threaded 64-bit Power architecture e6500 cores, up to 1.8GHz
- 2MB L2 cache and 512KB CoreNet platform cache (CPC)
- Hierarchical interconnect fabric
- One 32-/64-bit DDR3/3L SDRAM memory controllers with ECC and interleaving
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- 16 SerDes lanes up to 10.3125 GHz
- 8 Ethernet interfaces (multiple 1G/2.5G/10G MACs)
- High-speed peripheral interfaces
- Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0)
- Two Serial RapidIO 2.0 controllers/ports running at up to 5 GHz
- Additional peripheral interfaces
- Two serial ATA (SATA 2.0) controllers
- Two high-speed USB 2.0 controllers with integrated PHY
- Enhanced secure digital host controller (SD/SDXC/eMMC)
- Enhanced serial peripheral interface (eSPI)
- Four I2C controllers
- Four 2-pin UARTs or two 4-pin UARTs
- Integrated Flash Controller supporting NAND and NOR flash
- Three eight-channel DMA engines
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0
T2081 is a reduced personality of T2080 with following difference:
Feature T2080 T2081
1G Ethernet numbers: 8 6
10G Ethernet numbers: 4 2
SerDes lanes: 168
Serial RapidIO,RMan: 2 no
SATA Controller: 2 no
Aurora: yes no
SoC Package: 896-pins 780-pins
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
v3: added pamu node and updated clockgen.
v2: updated with some comments.
arch/powerpc/boot/dts/fsl/t2080si-post.dtsi | 69 +
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 434
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi | 91 ++
arch/powerpc/include/asm/mpc85xx.h | 2 +
4 files changed, 596 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t2081si-post.dtsi
create mode 100644 arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
new file mode 100644
index 000..082ec20
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/t2080si-post.dtsi
@@ -0,0 +1,69 @@
+/*
+ * T2080 Silicon/SoC Device Tree Source (post include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License (GPL) as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/include/ t2081si-post.dtsi
+
+soc {
+/include/ qoriq-sata2-0.dtsi
+ sata@22 {
+ fsl,iommu-parent = pamu1;
+ fsl,liodn-reg = guts 0x550; /* SATA1LIODNR */
+ };
+
+/include/ qoriq-sata2-1.dtsi
+ sata@221000 {
+ fsl,iommu-parent = pamu1;
+ fsl,liodn-reg = guts 0x554; /* SATA2LIODNR */
+ };
+};
+
+rio {
+ compatible = fsl,srio;
+ interrupts = 16
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
Yep, that makes sense. But unfortunately I don't have enough insight into
why exactly powerpc has to online the CPUs before doing a kexec. I just
know from the commit log and the comment mentioned above (and from my own
experiments) that the CPUs will get stuck if they were offline. Perhaps
somebody more knowledgeable can explain this in detail and suggest a proper
long-term solution.
Matt, Ben, any thoughts on this?
The problem is with our soft offline which we do on some platforms. When we
offline we don't actually send the CPUs back to firmware or anything like
that.
We put them into a very low low power loop inside Linux.
The new kernel has no way to extract them from that loop. So we must
re-online
them before we kexec so they can be passed to the new kernel normally (or
returned
to firmware like we do on powernv).
Thanks a lot for the explanation Ben!
I thought about this and this is what I think: whether the CPU is in the kernel
or in the firmware is a hard-boundary. But once we know it is still in the
kernel, whether it is online or offline is a soft-boundary, something that
ideally shouldn't make any difference to kexec.
Then I looked at what is that special state that kexec expects the online CPUs
to be in, before performing kexec, and I found that that state is entered via
kexec_smp_down().
Which means, if we poke the soft-offline CPUs and make them execute
kexec_smp_down(), we should be able to do a successful kexec without having to
actually online them. After all, the core kexec code doesn't mandate that they
should be online. So if we satisfy powerpc's requirement that all the CPUs are
in a sane state, that should be good enough. (This would be similar to how the
subcore code wakes up offline CPUs to perform the split-core procedure).
I know, this is all theory for now since I haven't tested it yet, but I think
we can make this work.
Below are the 4 preliminary patches I'm have so far, to implement this.
===
Patch 1
===
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 16d7e33..2a31b52 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -68,6 +68,7 @@ static inline void crash_setup_regs(struct pt_regs *newregs,
ppc_save_regs(newregs);
}
+extern bool kexec_cpu_wake(void);
extern void kexec_smp_wait(void); /* get and clear naca physid, wait for
master to copy new code to 0 */
extern int crashing_cpu;
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index f92b0b5..39f721d 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -255,6 +255,16 @@ struct machdep_calls {
void (*machine_shutdown)(void);
#ifdef CONFIG_KEXEC
+#if (defined CONFIG_PPC64) (defined CONFIG_PPC_BOOK3S)
+
+ /*
+* The pseries and powernv book3s platforms have a special requirement
+* that soft-offline CPUs have to be woken up before kexec, to avoid
+* CPUs getting stuck. This callback prepares the system for the
+* impending wakeup of the offline CPUs.
+*/
+ void (*kexec_wake_prepare)(void);
+#endif
void (*kexec_cpu_down)(int crash_shutdown, int secondary);
/* Called to do what every setup is needed on image and the
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 879b3aa..2ef6c58 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -182,6 +182,14 @@ static void kexec_smp_down(void *arg)
/* NOTREACHED */
}
+bool kexec_cpu_wake(void)
+{
+ kexec_smp_down(NULL);
+
+ /* NOTREACHED */
+ return true;
+}
+
static void kexec_prepare_cpus_wait(int wait_state)
{
int my_cpu, i, notified=-1;
@@ -202,7 +210,7 @@ static void kexec_prepare_cpus_wait(int wait_state)
* these possible-but-not-online-but-should-be CPUs and chaperone them
* into kexec_smp_wait().
*/
- for_each_online_cpu(i) {
+ for_each_present_cpu(i) {
if (i == my_cpu)
continue;
@@ -228,6 +236,8 @@ static void kexec_prepare_cpus_wait(int wait_state)
* threads as offline -- and again, these CPUs will be stuck.
*
* So, we online all CPUs that should be running, including secondary threads.
+ *
+ * TODO: Update this comment
*/
static void wake_offline_cpus(void)
{
@@ -237,7 +247,8 @@ static void wake_offline_cpus(void)
if (!cpu_online(cpu)) {
printk(KERN_INFO kexec: Waking offline cpu %d.\n,
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/04/2014 07:16 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs before doing a kexec. I just know from the commit log and the comment mentioned above (and from my own experiments) that the CPUs will get stuck if they were offline. Perhaps somebody more knowledgeable can explain this in detail and suggest a proper long-term solution. Matt, Ben, any thoughts on this? The problem is with our soft offline which we do on some platforms. When we offline we don't actually send the CPUs back to firmware or anything like that. We put them into a very low low power loop inside Linux. The new kernel has no way to extract them from that loop. So we must re-online them before we kexec so they can be passed to the new kernel normally (or returned to firmware like we do on powernv). Srivatsa, Looks like your patch has been merged. I don't like the following change in arch independent code. /* * migrate_to_reboot_cpu() disables CPU hotplug assuming that * no further code needs to use CPU hotplug (which is true in * the reboot case). However, the kexec path depends on using * CPU hotplug again; so re-enable it here. */ cpu_hotplug_enable(); As it is very powerpc specific requirement, can you enable hotplug in powerpc arch dependent code as a short term solution. I didn't do that because that would mean that the _disable() would be performed inside kernel/kexec.c and the corresponding _enable() would be performed in arch/powerpc/kernel/machine_kexec_64.c -- with no apparent connection between them, which would have made them hard to relate. Ideally one needs to fix the requirement of online all cpus in powerpc as a long term solution and then get rid of hotplug enable call. Yes, I agree. I'm trying out a solution at the moment (see the 4 preliminary patches I sent in my reply to Ben). If that works, we won't need the enable call on powerpc. Regards, Srivatsa S. Bhat ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/04/2014 07:11 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote: On 05/28/2014 07:01 PM, Vivek Goyal wrote: On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote: If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages during boot: [...] diff --git a/kernel/kexec.c b/kernel/kexec.c index c8380ad..28c5706 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1683,6 +1683,14 @@ int kernel_kexec(void) kexec_in_progress = true; kernel_restart_prepare(NULL); migrate_to_reboot_cpu(); + + /* + * migrate_to_reboot_cpu() disables CPU hotplug assuming that + * no further code needs to use CPU hotplug (which is true in + * the reboot case). However, the kexec path depends on using + * CPU hotplug again; so re-enable it here. + */ + cpu_hotplug_enable(); printk(KERN_EMERG Starting new kernel\n); machine_shutdown(); After migrate_to_reboot_cpu(), we are calling machine_shutdown() which calls disable_nonboot_cpus() and which in turn calls _cpu_down(). Hmm? I see only 'arm' calling disable_nonboot_cpus() from machine_shutdown(). None of the other architectures call it. Is that a leftover in arm? You are right. I did not notice that only arm is doing that. Looks like it is calling into some platform code, I am not sure what exactly arm does for disabling cpu. x86 code calls stop_other_cpus() in machine_shutdown() which sends REBOOT_VECTOR to other cpus and calls stop_this_cpu() which in turn does. for (;;) halt(); IIUC, upon receipt of certain interrupts cpu will come out of halt state. Not sure how safe it is from kexec point of view as we will be replacing original kernel that means if cpu comes out of halt state it might be running some random code. Eric/hpa might know better the context here and what safeguards us on x86. So one should not make cpu spin on some code as kexec will change that code. It should be some other platform specific mechanism which brings cpu in to hlt like state. So that way arm seems to be doing right thing. I am not sure what powerpc does to stop cpus. powerpc shepherds all CPUs to a safe state, by making them run kexec_smp_down(), and eventually those CPUs end up calling kexec_wait() in assembly. Regards, Srivatsa S. Bhat ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote:
+bool kexec_cpu_wake(void)
+{
+ kexec_smp_down(NULL);
+
+ /* NOTREACHED */
+ return true;
+}
+
This function doesn't have to return anything, so we can define it as void.
The bool is a remnant of my previous attempt at making this work. (But these
patches compile fine as they are, though).
Regards,
Srivatsa S. Bhat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cpufreq: ppc-corenet-cpu-freq: do_div use quotient
On 06/04/2014 02:32 PM, Ed Swarthout wrote: 6712d2931933ada259b82f06c03a855b19937074 (cpufreq: ppc-corenet-cpufreq: Fix __udivdi3 modpost error) used the remainder from do_div instead of the quotient. Fix that and add one to ensure minimum is met. Signed-off-by: Ed Swarthout ed.swarth...@freescale.com --- drivers/cpufreq/ppc-corenet-cpufreq.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c b/drivers/cpufreq/ppc-corenet-cpufreq.c index 0af618a..3607070 100644 --- a/drivers/cpufreq/ppc-corenet-cpufreq.c +++ b/drivers/cpufreq/ppc-corenet-cpufreq.c @@ -138,7 +138,7 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy) struct cpufreq_frequency_table *table; struct cpu_data *data; unsigned int cpu = policy-cpu; - u64 transition_latency_hz; + u64 u64temp; np = of_get_cpu_node(cpu, NULL); if (!np) @@ -206,9 +206,10 @@ static int corenet_cpufreq_cpu_init(struct cpufreq_policy *policy) for_each_cpu(i, per_cpu(cpu_mask, cpu)) per_cpu(cpu_data, i) = data; - transition_latency_hz = 12ULL * NSEC_PER_SEC; - policy-cpuinfo.transition_latency = - do_div(transition_latency_hz, fsl_get_sys_freq()); + /* Minimum transition latency is 12 platform clocks */ + u64temp = 12ULL * NSEC_PER_SEC; + do_div(u64temp, fsl_get_sys_freq()); + policy-cpuinfo.transition_latency = u64temp + 1; of_node_put(np); Whoops, what was I thinking ? You should also add Cc: sta...@vger.kernel.org # 3.15+ since this patch will likely miss 3.15 final. Acked-by: Tim Gardner tim.gard...@canonical.com -- Tim Gardner tim.gard...@canonical.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/4] KVM: PPC: BOOK3S: PR: Emulate virtual timebase register
Alexander Graf ag...@suse.de writes: On 05.06.14 14:08, Aneesh Kumar K.V wrote: virtual time base register is a per VM, per cpu register that needs to be saved and restored on vm exit and entry. Writing to VTB is not allowed in the privileged mode. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com For some reason BUG() doesn't always trigger the execution stops here logic in gcc. So I've squashed this patch into yours. Alex diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h index 3e7085d..99de6ad 100644 --- a/arch/powerpc/include/asm/reg.h +++ b/arch/powerpc/include/asm/reg.h @@ -1206,6 +1206,7 @@ static inline unsigned long mfvtb (void) * capture that. */ BUG(); +return 0; } #ifdef __powerpc64__ you can then drop the include header change. ie, #include asm/bug.h -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/powernv: Fix endian issues in memory error handling code
On 2014-06-04 14:48:48 Wed, Anton Blanchard wrote:
struct OpalMemoryErrorData is passed to us from firmware, so we
have to byteswap it.
Signed-off-by: Anton Blanchard an...@samba.org
Tested-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
Having enums in a firmware interface concerns me, but that cleanup
can be in a subsequent patch.
Mahesh, could you give this a test to see if it works?
Index: b/arch/powerpc/include/asm/opal.h
===
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -482,7 +482,7 @@ enum OpalMemErr_DynErrType {
struct OpalMemoryErrorData {
enum OpalMemErr_Version version:8; /* 0x00 */
enum OpalMemErrType type:8; /* 0x01 */
- uint16_tflags; /* 0x02 */
+ __be16 flags; /* 0x02 */
uint8_t reserved_1[4]; /* 0x04 */
union {
@@ -490,15 +490,15 @@ struct OpalMemoryErrorData {
struct {
enum OpalMemErr_ResilErrType resil_err_type:8;
uint8_t reserved_1[7];
- uint64_tphysical_address_start;
- uint64_tphysical_address_end;
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} resilience;
/* Dynamic memory deallocation error info */
struct {
enum OpalMemErr_DynErrType dyn_err_type:8;
uint8_t reserved_1[7];
- uint64_tphysical_address_start;
- uint64_tphysical_address_end;
+ __be64 physical_address_start;
+ __be64 physical_address_end;
} dyn_dealloc;
} u;
};
Index: b/arch/powerpc/platforms/powernv/opal-memory-errors.c
===
--- a/arch/powerpc/platforms/powernv/opal-memory-errors.c
+++ b/arch/powerpc/platforms/powernv/opal-memory-errors.c
@@ -47,12 +47,12 @@ static void handle_memory_error_event(st
__func__, merr_evt-type);
switch (merr_evt-type) {
case OPAL_MEM_ERR_TYPE_RESILIENCE:
- paddr_start = merr_evt-u.resilience.physical_address_start;
- paddr_end = merr_evt-u.resilience.physical_address_end;
+ paddr_start =
be64_to_cpu(merr_evt-u.resilience.physical_address_start);
+ paddr_end =
be64_to_cpu(merr_evt-u.resilience.physical_address_end);
break;
case OPAL_MEM_ERR_TYPE_DYN_DALLOC:
- paddr_start = merr_evt-u.dyn_dealloc.physical_address_start;
- paddr_end = merr_evt-u.dyn_dealloc.physical_address_end;
+ paddr_start =
be64_to_cpu(merr_evt-u.dyn_dealloc.physical_address_start);
+ paddr_end =
be64_to_cpu(merr_evt-u.dyn_dealloc.physical_address_end);
break;
default:
return;
--
Mahesh J Salgaonkar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9 3/3] drivers/vfio: EEH support for VFIO PCI device
On Fri, 2014-06-06 at 15:00 +1000, Gavin Shan wrote:
The patch adds new IOCTL commands for sPAPR VFIO container device
to support EEH functionality for PCI devices, which have been passed
through from host to somebody else via VFIO.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Acked-by: Alexander Graf ag...@suse.de
---
Documentation/vfio.txt | 87
+++--
drivers/vfio/Makefile | 1 +
drivers/vfio/pci/vfio_pci.c | 18 ++--
drivers/vfio/vfio_iommu_spapr_tce.c | 17 +++-
drivers/vfio/vfio_spapr_eeh.c | 87
+
include/linux/vfio.h| 23 ++
include/uapi/linux/vfio.h | 34 +++
7 files changed, 259 insertions(+), 8 deletions(-)
create mode 100644 drivers/vfio/vfio_spapr_eeh.c
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index b9ca023..3fa4538 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -305,7 +305,15 @@ faster, the map/unmap handling has been implemented in
real mode which provides
an excellent performance which has limitations such as inability to do
locked pages accounting in real time.
-So 3 additional ioctls have been added:
+4) According to sPAPR specification, A Partitionable Endpoint (PE) is an I/O
+subtree that can be treated as a unit for the purposes of partitioning and
+error recovery. A PE may be a single or multi-function IOA (IO Adapter), a
+function of a multi-function IOA, or multiple IOAs (possibly including switch
+and bridge structures above the multiple IOAs). PPC64 guests detect PCI
errors
+and recover from them via EEH RTAS services, which works on the basis of
+additional ioctl commands.
+
+So 4 additional ioctls have been added:
VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
of the DMA window on the PCI bus.
@@ -316,9 +324,12 @@ So 3 additional ioctls have been added:
VFIO_IOMMU_DISABLE - disables the container.
+ VFIO_EEH_PE_OP - provides an API for EEH setup, error detection and
recovery.
The code flow from the example above should be slightly changed:
+ struct vfio_eeh_pe_op pe_op = { .argsz = sizeof(pe_op) };
+
.
/* Add the group to the container */
ioctl(group, VFIO_GROUP_SET_CONTAINER, container);
@@ -342,9 +353,79 @@ The code flow from the example above should be slightly
changed:
dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
/* Check here is .iova/.size are within DMA window from
spapr_iommu_info */
-
ioctl(container, VFIO_IOMMU_MAP_DMA, dma_map);
- .
+
+ /* Get a file descriptor for the device */
+ device = ioctl(group, VFIO_GROUP_GET_DEVICE_FD, :06:0d.0);
+
+
+
+ /* Gratuitous device reset and go... */
+ ioctl(device, VFIO_DEVICE_RESET);
+
+ /* Make sure EEH is supported */
+ ioctl(container, VFIO_CHECK_EXTENSION, VFIO_EEH);
+
+ /* Enable the EEH functionality on the device */
+ pe_op.op = VFIO_EEH_PE_ENABLE;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /* You're suggested to create additional data struct to represent
+ * PE, and put child devices belonging to same IOMMU group to the
+ * PE instance for later reference.
+ */
+
+ /* Check the PE's state and make sure it's in functional state */
+ pe_op.op = VFIO_EEH_PE_GET_STATE;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /* Save device state using pci_save_state().
+ * EEH should be enabled on the specified device.
+ */
+
+
+
+ /* When 0xFF's returned from reading PCI config space or IO BARs
+ * of the PCI device. Check the PE's state to see if that has been
+ * frozen.
+ */
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /* Waiting for pending PCI transactions to be completed and don't
+ * produce any more PCI traffic from/to the affected PE until
+ * recovery is finished.
+ */
+
+ /* Enable IO for the affected PE and collect logs. Usually, the
+ * standard part of PCI config space, AER registers are dumped
+ * as logs for further analysis.
+ */
+ pe_op.op = VFIO_EEH_PE_UNFREEZE_IO;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /*
+ * Issue PE reset: hot or fundamental reset. Usually, hot reset
+ * is enough. However, the firmware of some PCI adapters would
+ * require fundamental reset.
+ */
+ pe_op.op = VFIO_EEH_PE_RESET_HOT;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+ pe_op.op = VFIO_EEH_PE_RESET_DEACTIVATE;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /* Configure the PCI bridges for the affected PE */
+ pe_op.op = VFIO_EEH_PE_CONFIGURE;
+ ioctl(container, VFIO_EEH_PE_OP, pe_op);
+
+ /* Restored state we saved at
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On Fri, Jun 06, 2014 at 06:00:43PM +0530, Srivatsa S. Bhat wrote: On 06/04/2014 07:16 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs before doing a kexec. I just know from the commit log and the comment mentioned above (and from my own experiments) that the CPUs will get stuck if they were offline. Perhaps somebody more knowledgeable can explain this in detail and suggest a proper long-term solution. Matt, Ben, any thoughts on this? The problem is with our soft offline which we do on some platforms. When we offline we don't actually send the CPUs back to firmware or anything like that. We put them into a very low low power loop inside Linux. The new kernel has no way to extract them from that loop. So we must re-online them before we kexec so they can be passed to the new kernel normally (or returned to firmware like we do on powernv). Srivatsa, Looks like your patch has been merged. I don't like the following change in arch independent code. /* * migrate_to_reboot_cpu() disables CPU hotplug assuming that * no further code needs to use CPU hotplug (which is true in * the reboot case). However, the kexec path depends on using * CPU hotplug again; so re-enable it here. */ cpu_hotplug_enable(); As it is very powerpc specific requirement, can you enable hotplug in powerpc arch dependent code as a short term solution. I didn't do that because that would mean that the _disable() would be performed inside kernel/kexec.c and the corresponding _enable() would be performed in arch/powerpc/kernel/machine_kexec_64.c -- with no apparent connection between them, which would have made them hard to relate. Which we are doing anyway. The difference is that now we are doing it for all arches. If this is powerpc specific requirement, then we should limit this to powerpc only and not let spill over in generic code. And putting a big fat comment should take care of being able to figure out why arch code is overwriting the generic code's decision. By putting it in generic code and enforcing this on all arches does not buy us anything, IMHO. Ideally one needs to fix the requirement of online all cpus in powerpc as a long term solution and then get rid of hotplug enable call. Yes, I agree. I'm trying out a solution at the moment (see the 4 preliminary patches I sent in my reply to Ben). If that works, we won't need the enable call on powerpc. Thanks. This will help. Thanks Vivek ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/06/2014 11:57 PM, Vivek Goyal wrote: On Fri, Jun 06, 2014 at 06:00:43PM +0530, Srivatsa S. Bhat wrote: On 06/04/2014 07:16 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs before doing a kexec. I just know from the commit log and the comment mentioned above (and from my own experiments) that the CPUs will get stuck if they were offline. Perhaps somebody more knowledgeable can explain this in detail and suggest a proper long-term solution. Matt, Ben, any thoughts on this? The problem is with our soft offline which we do on some platforms. When we offline we don't actually send the CPUs back to firmware or anything like that. We put them into a very low low power loop inside Linux. The new kernel has no way to extract them from that loop. So we must re-online them before we kexec so they can be passed to the new kernel normally (or returned to firmware like we do on powernv). Srivatsa, Looks like your patch has been merged. I don't like the following change in arch independent code. /* * migrate_to_reboot_cpu() disables CPU hotplug assuming that * no further code needs to use CPU hotplug (which is true in * the reboot case). However, the kexec path depends on using * CPU hotplug again; so re-enable it here. */ cpu_hotplug_enable(); As it is very powerpc specific requirement, can you enable hotplug in powerpc arch dependent code as a short term solution. I didn't do that because that would mean that the _disable() would be performed inside kernel/kexec.c and the corresponding _enable() would be performed in arch/powerpc/kernel/machine_kexec_64.c -- with no apparent connection between them, which would have made them hard to relate. Which we are doing anyway. The difference is that now we are doing it for all arches. If this is powerpc specific requirement, then we should limit this to powerpc only and not let spill over in generic code. And putting a big fat comment should take care of being able to figure out why arch code is overwriting the generic code's decision. By putting it in generic code and enforcing this on all arches does not buy us anything, IMHO. Yep, I see your point. Sorry about that! Actually, I originally thought of fixing cpu_hotplug_disable/enable itself: their true intent is to prevent *userspace* (i.e., from sysfs) from performing CPU hotplug after a certain quiescent point in the kernel, and not to prevent the kernel's own cpu hotplug attempts. But currently it prevents _all_ hotplug, including those that are initiated from within the kernel, which is the reason why kexec was effectively locking itself out on powerpc. I explored options to fix that (which would in turn fix the powerpc problem automatically, without having to add any code to kernel/kexec.c or even arch/powerpc code). But it turned out to be too difficult and ugly given the current CPU hotplug locking scheme. I'll revisit that once CPU hotplug locking is cleaned up. But anyway, the powerpc kexec fix that I'm working on right now is not only a much better solution, but it will also restore the original kexec code in kernel/kexec.c, by removing the _enable() call. Thank you! Regards, Srivatsa S. Bhat ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH][v10] powerpc/mpc85xx:Add initial device tree support of T104x
On Fri, 2014-06-06 at 00:04 -0500, Liu Shengzhou-B36685 wrote:
-Original Message-
From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-
release-boun...@linux.freescale.net] On Behalf Of Prabhakar Kushwaha
Sent: Monday, April 21, 2014 7:34 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Wood Scott-B07421; Jain Priyanka-B32167; Aggrwal Poonam-B10812;
Kushwaha Prabhakar-B32579
Subject: [linuxppc-release] [PATCH][v10] powerpc/mpc85xx:Add initial
device tree support of T104x
The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
processor cores with high-performance data path acceleration architecture
and network peripheral interfaces required for networking
telecommunications.
+
+ iommu@2 {
+ compatible = fsl,pamu-v1.0, fsl,pamu;
+ reg = 0x2 0x1000;
+ ranges = 0 0x2 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupts =
+ 24 2 0 0
+ 16 2 1 30;
+ pamu0: pamu@0 {
+ reg = 0 0x1000;
+ fsl,primary-cache-geometry = 128 1;
+ fsl,secondary-cache-geometry = 16 2;
+ };
[Shengzhou] T1040 RM says:
Hardware coherent PAMU Look-aside caches to improve performance
* A 32-entry, direct-mapped primary PAACT cache
* A 128-entry, 2-way, set-associative secondary PAACT cache
It appears it should be:
fsl,primary-cache-geometry = 32 1;
fsl,secondary-cache-geometry = 128 2;
is there any reason that it was 128 1, 16 2 ?
The B4 device trees are also suspicous.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote:
On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote:
On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote:
Yep, that makes sense. But unfortunately I don't have enough insight into
why exactly powerpc has to online the CPUs before doing a kexec. I just
know from the commit log and the comment mentioned above (and from my own
experiments) that the CPUs will get stuck if they were offline. Perhaps
somebody more knowledgeable can explain this in detail and suggest a proper
long-term solution.
Matt, Ben, any thoughts on this?
The problem is with our soft offline which we do on some platforms. When we
offline we don't actually send the CPUs back to firmware or anything like
that.
We put them into a very low low power loop inside Linux.
The new kernel has no way to extract them from that loop. So we must
re-online
them before we kexec so they can be passed to the new kernel normally (or
returned
to firmware like we do on powernv).
Thanks a lot for the explanation Ben!
I thought about this and this is what I think: whether the CPU is in the
kernel
or in the firmware is a hard-boundary. But once we know it is still in the
kernel, whether it is online or offline is a soft-boundary, something that
ideally shouldn't make any difference to kexec.
Then I looked at what is that special state that kexec expects the online CPUs
to be in, before performing kexec, and I found that that state is entered via
kexec_smp_down().
Which means, if we poke the soft-offline CPUs and make them execute
kexec_smp_down(), we should be able to do a successful kexec without having to
actually online them. After all, the core kexec code doesn't mandate that they
should be online. So if we satisfy powerpc's requirement that all the CPUs are
in a sane state, that should be good enough. (This would be similar to how the
subcore code wakes up offline CPUs to perform the split-core procedure).
I know, this is all theory for now since I haven't tested it yet, but I think
we can make this work.
Below are the 4 preliminary patches I'm have so far, to implement this.
And with the following hunk added (which I had forgotten earlier), it worked
just
fine on powernv :-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c
b/arch/powerpc/kernel/machine_kexec_64.c
index 2ef6c58..84e91293 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -243,6 +243,9 @@ static void wake_offline_cpus(void)
{
int cpu = 0;
+ if (ppc_md.kexec_wake_prepare)
+ ppc_md.kexec_wake_prepare();
+
for_each_present_cpu(cpu) {
if (!cpu_online(cpu)) {
printk(KERN_INFO kexec: Waking offline cpu %d.\n,
I tried putting the machine into ST mode, and in a separate experiment, I kept
just CPU 0 online in the first kernel, and then issued a kexec. The second
kernel
booted successfully with all the CPUs in both the cases.
I haven't explored the crashed-kernel case though, it might need some auditing
to check if the code handles that as well.
Regards,
Srivatsa S. Bhat
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/13] powerpc: Use list_add_(before|after) macros
From: Ken Helias kenhel...@firemail.de Many places in the code uses list_add_tail/list_add to insert an entry before/after another entry. This confuses the reader because these are usually used to add an item to a list_head and not an entry. Better use the self explaining function name. Signed-off-by: Ken Helias kenhel...@firemail.de Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/lib/rheap.c | 2 +- arch/powerpc/mm/dma-noncoherent.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c index a1060a8..d8c5f16 100644 --- a/arch/powerpc/lib/rheap.c +++ b/arch/powerpc/lib/rheap.c @@ -486,7 +486,7 @@ unsigned long rh_alloc_align(rh_info_t * info, int size, int alignment, const ch spblk-start = blk-start; spblk-size = sp_size; /* add before the blk */ - list_add(spblk-list, blk-list.prev); + list_add_before(spblk-list, blk-list); } newblk = get_slot(info); newblk-start = start; diff --git a/arch/powerpc/mm/dma-noncoherent.c b/arch/powerpc/mm/dma-noncoherent.c index d85e86a..222ae97 100644 --- a/arch/powerpc/mm/dma-noncoherent.c +++ b/arch/powerpc/mm/dma-noncoherent.c @@ -120,7 +120,7 @@ ppc_vm_region_alloc(struct ppc_vm_region *head, size_t size, gfp_t gfp) /* * Insert this entry _before_ the one we found. */ - list_add_tail(new-vm_list, c-vm_list); + list_add_before(new-vm_list, c-vm_list); new-vm_start = addr; new-vm_end = addr + size; -- 2.0.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powernv: Fix permissions on sysparam sysfs entries
Everyone can write to these files, which is not what we want. Cc: sta...@vger.kernel.org # 3.15 Signed-off-by: Anton Blanchard an...@samba.org --- diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c b/arch/powerpc/platforms/powernv/opal-sysparam.c index d202f9b..9d1acf2 100644 --- a/arch/powerpc/platforms/powernv/opal-sysparam.c +++ b/arch/powerpc/platforms/powernv/opal-sysparam.c @@ -260,10 +260,10 @@ void __init opal_sys_param_init(void) attr[i].kobj_attr.attr.mode = S_IRUGO; break; case OPAL_SYSPARAM_WRITE: - attr[i].kobj_attr.attr.mode = S_IWUGO; + attr[i].kobj_attr.attr.mode = S_IWUSR; break; case OPAL_SYSPARAM_RW: - attr[i].kobj_attr.attr.mode = S_IRUGO | S_IWUGO; + attr[i].kobj_attr.attr.mode = S_IRUGO | S_IWUSR; break; default: break; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] crypto/nx: disable NX on little endian builds
The NX driver has endian issues so disable it for now. Signed-off-by: Anton Blanchard an...@samba.org --- diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 03ccdb0..8280a7a3 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -313,7 +313,7 @@ config CRYPTO_DEV_S5P config CRYPTO_DEV_NX bool Support for IBM Power7+ in-Nest cryptographic acceleration - depends on PPC64 IBMVIO + depends on PPC64 IBMVIO !CPU_LITTLE_ENDIAN default n help Support for Power7+ in-Nest cryptographic acceleration. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git next branch
Hi Linus ! Here is the bulk of the powerpc changes for this merge window. It got a bit delayed in part because I wasn't paying attention, and in part because I discovered I had a core PCI change without a PCI maintainer ack in it. Bjorn eventually agreed it was ok to merge it though we'll probably improve it later and I didn't want to rebase to add his ack. There is going to be a bit more next week, essentially fixes that I still want to sort through and test. The biggest item this time is the support to build the ppc64 LE kernel with our new v2 ABI. We previously supported v2 userspace but the kernel itself was a tougher nut to crack. This is now sorted mostly thanks to Anton and Rusty. We also have a fairly big series from Cedric that add support for 64-bit LE zImage boot wrapper. This was made harder by the fact that traditionally our zImage wrapper was always 32-bit, but our new LE toolchains don't really support 32-bit anymore (it's somewhat there but not really supported) so we didn't want to rely on it. This meant more churn that just endian fixes. This brings some more LE bits as well, such as the ability to run in LE mode without a hypervisor (ie. under OPAL firmware) by doing the right OPAL call to reinitialize the CPU to take HV interrupts in the right mode and the usual pile of endian fixes. There's another series from Gavin adding EEH improvements (one day we *will* have a release with less than 20 EEH patches, I promise !). Another highlight is the support for the Split core functionality on P8 by Michael. This allows a P8 core to be split into sub cores of 4 threads which allows the subcores to run different guests under KVM (the HW still doesn't support a partition per thread). And then the usual misc bits and fixes ... Cheers, Ben. The following changes since commit 011e4b02f1da156ac7fea28a9da878f3c23af739: powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode (2014-05-28 13:24:26 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next for you to fetch changes up to 0c0a3e5a100bbc4aaedd140e82b429227a76701b: powerpc/powernv: Add missing include to LPC code (2014-06-07 08:57:21 +1000) Alexander Graf (2): powerpc: Use 64k io pages when we never see an HEA PPC: ePAPR: Fix hypercall on LE guest Alistair Popple (4): IBM Currituck: Clean up board specific code before adding Akebono code IBM Akebono: Add the Akebono platform powerpc: Added PCI MSI support using the HSTA module ppc476: Enable a linker work around for IBM errata #46 Andrew Murray (1): powerpc/pci: Use of_pci_range_parser helper in pci_process_bridge_OF_ranges Anton Blanchard (36): powerpc: Don't build assembly files with ABIv2 powerpc: No need to use dot symbols when branching to a function powerpc: Remove superflous function descriptors in assembly only code powerpc: Don't use a function descriptor for system call table powerpc: Remove some unnecessary uses of _GLOBAL() and _STATIC() powerpc: Remove _INIT_GLOBAL(), _STATIC() and _INIT_STATIC() powerpc: Remove dot symbol usage in exception macros powerpc: Create DOTSYM to wrap dot symbol usage powerpc: Remove function descriptors and dot symbols on new ABI powerpc: ABIv2 function calls must place target address in r12 powerpc: Ignore .TOC. relocations powerpc: Add ABIv2 support to ppc_function_entry powerpc: Use ppc_function_entry instead of open coding it powerpc: Fix branch patching code for ABIv2 powerpc: Fix kernel thread creation on ABIv2 powerpc: Fix ABIv2 issues with stack offsets in assembly code powerpc/tm: Use STK_PARAM powerpc/tm: Fix GOT save offset for ABIv2 powerpc/tracing: TRACE_WITH_FRAME_BUFFER creates invalid stack frames powerpc: Fix SMP issues with ppc64le ABIv2 powerpc: Fix ABIv2 issue with dereference_function_descriptor powerpc: Add _GLOBAL_TOC for ABIv2 assembly functions exported to modules powerpc: ftrace_caller, _mcount is exported to modules so needs _GLOBAL_TOC() powerpc/kprobes: Fix ABIv2 issues with kprobe_lookup_name powerpc/modules: Create is_module_trampoline() powerpc/modules: Create module_trampoline_target() powerpc/ftrace: Use module loader helpers to parse trampolines powerpc/ftrace: Fix ABIv2 issues with __ftrace_make_call powerpc: Build little endian ppc64 kernel with ABIv2 selftests/powerpc: Update for ABIv2 powerpc: 64bit sendfile is capped at 2GB powerpc/powernv: Fix endian issues in memory error handling code powerpc: Allow ppc_md platform hook to override memory_block_size_bytes powerpc/powernv: Set memory_block_size_bytes to 256MB powerpc: Exported functions __clear_user and copy_page use r2 so need _GLOBAL_TOC()
