[RFC][PATCH] powerpc/CoreNet64: compile with CONFIG_E{5, 6}500_CPU well
CONFIG_ALTIVEC is always enabled for CoreNet64. And if we
select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec and Spe options not allowed with
e500mc64, so :
CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/lib/Makefile |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 95a20e1..641a77d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,5 +40,8 @@ obj-y += code-patching.o
obj-y += feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
+# Altivec and Spe options not allowed with e500mc64 in GCC.
+ifeq ($(call cc-option-yn,-mcpu=e500mc64),n)
obj-$(CONFIG_ALTIVEC) += xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec -mabi=altivec
+endif
--
1.7.9.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/eeh: Dump PHB3 diag-data on frozen PE
While we detect frozen PE on PHB3, it's always meaningful to have the dumped diag-data for further diagnosis and analysis. Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/eeh-ioda.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c index 02245ce..481528d 100644 --- a/arch/powerpc/platforms/powernv/eeh-ioda.c +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c @@ -994,8 +994,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe) if (ioda_eeh_get_pe(hose, frozen_pe_no, pe)) break; + /* It would be always indicative to have PHB diag-data */ pr_err(EEH: Frozen PE#%x on PHB#%x detected\n, (*pe)-addr, (*pe)-phb-global_number); + ioda_eeh_phb_diag(hose); + ret = 1; goto out; } -- 1.7.9.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/eeh: Dump PHB3 diag-data on frozen PE
On Wed, 2013-11-20 at 17:36 +0800, Gavin Shan wrote: While we detect frozen PE on PHB3, it's always meaningful to have the dumped diag-data for further diagnosis and analysis. Don't we trip that during PCI probing ? For example if we probe behind a PCI-X bridge (which can exist on an adapter) we'll trip EEH on every non-existing device won't we ? Cheers, Ben. Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/eeh-ioda.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c index 02245ce..481528d 100644 --- a/arch/powerpc/platforms/powernv/eeh-ioda.c +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c @@ -994,8 +994,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe) if (ioda_eeh_get_pe(hose, frozen_pe_no, pe)) break; + /* It would be always indicative to have PHB diag-data */ pr_err(EEH: Frozen PE#%x on PHB#%x detected\n, (*pe)-addr, (*pe)-phb-global_number); + ioda_eeh_phb_diag(hose); + ret = 1; goto out; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v7] clk: corenet: Adds the clock binding
From: Tang Yuantian yuantian.t...@freescale.com
Adds the clock bindings for Freescale PowerPC CoreNet platforms
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
v7:
- refined some properties' definitions
v6:
- splited the previous patch into 2 parts, one is for binding(this one),
the other is for DTS modification(will submit once this gets accepted)
- fixed typo
- refined #clock-cells and clock-output-names properties
- removed fixed-clock compatible string
v5:
- refine the binding document
- update the compatible string
v4:
- add binding document
- update compatible string
- update the reg property
v3:
- fix typo
v2:
- add t4240, b4420, b4860 support
- remove pll/4 clock from p2041, p3041 and p5020 board
.../devicetree/bindings/clock/corenet-clock.txt| 128 +
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/corenet-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt
b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 000..609ba2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,128 @@
+* Clock Block on Freescale CoreNet Platforms
+
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+which can then be passed to a variety of internal logic, including
+cores and peripheral IP blocks.
+Please refer to the Reference Manual for details.
+
+1. Clock Block Binding
+
+Required properties:
+- compatible: Should contain a specific clock block compatible string
+ and a single chassis clock compatible string.
+ Clock block strings include, but not limited to, one of the:
+ * fsl,p2041-clockgen
+ * fsl,p3041-clockgen
+ * fsl,p4080-clockgen
+ * fsl,p5020-clockgen
+ * fsl,p5040-clockgen
+ * fsl,t4240-clockgen
+ * fsl,b4420-clockgen
+ * fsl,b4860-clockgen
+ Chassis clock strings include:
+ * fsl,qoriq-clockgen-1.0: for chassis 1.0 clocks
+ * fsl,qoriq-clockgen-2.0: for chassis 2.0 clocks
+- reg: Offset and length of the clock register set
+
+Recommended properties:
+- ranges: Allows valid translation between child's address space and
+ parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+ physical base addresses. Must be present if the device has
+ sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+ the size of an address. Must be present if the device has
+ sub-nodes and set to 1 if present
+
+2. Clock Provider/Consumer Binding
+
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Should include one of the following:
+ * fsl,qoriq-core-pll-1.0 for core PLL clocks (v1.0)
+* fsl,qoriq-core-pll-2.0 for core PLL clocks (v2.0)
+* fsl,qoriq-core-mux-1.0 for core mux clocks (v1.0)
+* fsl,qoriq-core-mux-2.0 for core mux clocks (v2.0)
+ * fsl,qoriq-sysclk-1.0: for input system clock (v1.0)
+ * fsl,qoriq-sysclk-2.0: for input system clock (v2.0)
+- #clock-cells: From common clock binding. The number of cells in a
+ clock-specifier. Should be 0 for fsl,qoriq-sysclk-[1,2].0
+ clocks, or 1 for fsl,qoriq-core-pll-[1,2].0 clocks.
+ For fsl,qoriq-core-pll-[1,2].0 clocks, the single
+ clock-specifier cell may take the following values:
+ * 0 - equal to the PLL frequency
+ * 1 - equal to the PLL frequency divided by 2
+ * 2 - equal to the PLL frequency divided by 4
+
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+ output clocks
+- reg: Should be the offset and length of clock block base address.
+ The length should be 4.
+
+Example for clock block and clock provider:
+/ {
+ clockgen: global-utilities@e1000 {
+ compatible = fsl,p5020-clockgen, fsl,qoriq-clockgen-1.0;
+ ranges = 0x0 0xe1000 0x1000;
+ reg = 0xe1000 0x1000;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ sysclk: sysclk {
+ #clock-cells = 0;
+ compatible = fsl,qoriq-sysclk-1.0;
+ clock-output-names = sysclk;
+ }
+
+ pll0: pll0@800 {
+ #clock-cells = 1;
+ reg = 0x800 0x4;
Re: [PATCH] powerpc/eeh: Dump PHB3 diag-data on frozen PE
On Wed, Nov 20, 2013 at 08:38:48PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2013-11-20 at 17:36 +0800, Gavin Shan wrote: While we detect frozen PE on PHB3, it's always meaningful to have the dumped diag-data for further diagnosis and analysis. Don't we trip that during PCI probing ? For example if we probe behind a PCI-X bridge (which can exist on an adapter) we'll trip EEH on every non-existing device won't we ? Yes, we already had the dumped PHB diag-data when detecting frozen PE during PCI probing. After PCI probing is completed, the EEH takes over and we won't dump PHB diag-data during PCI config cycles. Took a close look on what we have in the code. Those functions to dump PHB (P7IOC PHB3) needs a bit rework or refactoring since we're dumping same PHB diag-data in pci.c and eeh-ioda.c at the same time. Besides, I think the appropriate place to dump PHB diag-data (for EEH core itself) would be ioda_eeh_get_log(), which is the indirect backend of eeh_ops::get_log, instead of the function ioda_eeh_next_error(). Ben, please drop this one for now and I'll send the revised one :-) Thanks, Gavin Signed-off-by: Gavin Shan sha...@linux.vnet.ibm.com --- arch/powerpc/platforms/powernv/eeh-ioda.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c index 02245ce..481528d 100644 --- a/arch/powerpc/platforms/powernv/eeh-ioda.c +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c @@ -994,8 +994,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe) if (ioda_eeh_get_pe(hose, frozen_pe_no, pe)) break; +/* It would be always indicative to have PHB diag-data */ pr_err(EEH: Frozen PE#%x on PHB#%x detected\n, (*pe)-addr, (*pe)-phb-global_number); +ioda_eeh_phb_diag(hose); + ret = 1; goto out; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG: Patch Convert some mftb/mftbu into mfspr breaks MPC885
Scott, The patch Convert some mftb/mftbu into mfspr (beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885. The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to read TBU with mfspr. Reverting the patch solves the issue. What's the prefered way to fix this ? Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND v4] powerpc: kvm: fix rare but potential deadlock scene
Am 20.11.2013 um 03:42 schrieb Liu ping fan kernelf...@gmail.com: On Tue, Nov 19, 2013 at 6:39 PM, Alexander Graf ag...@suse.de wrote: On 19.11.2013, at 07:12, Liu Ping Fan kernelf...@gmail.com wrote: Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Suppose the following scene: Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus. If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in realmode for a long time. What makes things even worse if the following happens, On cpuM, bitlockX is hold, on cpuN, Y is hold. vcpu_B_2 try to lock Y on cpuM in realmode vcpu_A_2 try to lock X on cpuN in realmode Oops! deadlock happens Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com Any particular reason for the resend? The patch is already applied, no? Oh, seems that I misunderstood your meaning. You said Actually, I've changed my mind and moved the patch to the for-3.13 branch instead. Please make sure to CC kvm@vger on all patches you submit though. So I think it is necessary to resend with cc kvm@vger Oh. I meant for next time :). But now that it happened for this patch already it's even better. Thanks a lot! Alex Regards, Pingfan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/9] ppc64 little endian updates
This patch series adds support for the new ABI, LPAR support for H_SET_MODE and finally adds a kconfig option and defconfig. ABIv2 support was recently committed to binutils and gcc, and should be merged into glibc soon. There are a number of very nice improvements including the removal of function descriptors. Rusty's kernel patches allow binaries of either ABI to work, easing the transition. Alistair Popple (1): powerpc: Don't use ELFv2 ABI to build the kernel Anton Blanchard (4): powerpc/pseries: Fix endian issues in pseries EEH code pseries: Add H_SET_MODE to change exception endianness powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option. powerpc: Add pseries_le_defconfig Rusty Russell (4): powerpc: Add TIF_ELF2ABI flag. powerpc: Set eflags correctly for ELF ABIv2 core dumps. powerpc: ELF2 binaries launched directly. powerpc: ELF2 binaries signal handling arch/powerpc/Makefile| 1 + arch/powerpc/configs/pseries_le_defconfig| 352 +++ arch/powerpc/include/asm/elf.h | 4 + arch/powerpc/include/asm/hvcall.h| 2 + arch/powerpc/include/asm/plpar_wrappers.h| 26 ++ arch/powerpc/include/asm/thread_info.h | 9 + arch/powerpc/kernel/process.c| 50 ++-- arch/powerpc/kernel/signal_64.c | 25 +- arch/powerpc/platforms/Kconfig.cputype | 11 + arch/powerpc/platforms/pseries/eeh_pseries.c | 21 +- arch/powerpc/platforms/pseries/lpar.c| 17 ++ arch/powerpc/platforms/pseries/setup.c | 42 12 files changed, 527 insertions(+), 33 deletions(-) create mode 100644 arch/powerpc/configs/pseries_le_defconfig -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/9] powerpc: Add TIF_ELF2ABI flag.
From: Rusty Russell ru...@rustcorp.com.au
Little endian ppc64 is getting an exciting new ABI. This is reflected
by the bottom two bits of e_flags in the ELF header:
0 == legacy binaries (v1 ABI)
1 == binaries using the old ABI (compiled with a new toolchain)
2 == binaries using the new ABI.
We store this in a thread flag, because we need to set it in core
dumps and for signal delivery. Our chief concern is that it doesn't
use function descriptors.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/include/asm/elf.h | 2 ++
arch/powerpc/include/asm/thread_info.h | 9 +
2 files changed, 11 insertions(+)
diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h
index cc0655a..6d0e236 100644
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -86,6 +86,8 @@ typedef elf_vrregset_t elf_fpxregset_t;
#ifdef __powerpc64__
# define SET_PERSONALITY(ex) \
do { \
+ if (((ex).e_flags 0x3) == 2) \
+ set_thread_flag(TIF_ELF2ABI); \
if ((ex).e_ident[EI_CLASS] == ELFCLASS32) \
set_thread_flag(TIF_32BIT); \
else\
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index ba7b197..05a3030 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -107,6 +107,9 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_EMULATE_STACK_STORE16 /* Is an instruction emulation
for stack store? */
#define TIF_MEMDIE 17 /* is terminating due to OOM killer */
+#if defined(CONFIG_PPC64)
+#define TIF_ELF2ABI18 /* function descriptors must die! */
+#endif
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1TIF_SYSCALL_TRACE)
@@ -185,6 +188,12 @@ static inline bool test_thread_local_flags(unsigned int
flags)
#define is_32bit_task()(1)
#endif
+#if defined(CONFIG_PPC64)
+#define is_elf2_task() (test_thread_flag(TIF_ELF2ABI))
+#else
+#define is_elf2_task() (0)
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 5/9] powerpc: ELF2 binaries launched directly.
From: Rusty Russell ru...@rustcorp.com.au
No function descriptor, but we set r12 up and set TIF_RESTOREALL as it
normally isn't restored on return from syscall.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/kernel/process.c | 50 ++-
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 75c2d10..0650e18 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1086,25 +1086,45 @@ void start_thread(struct pt_regs *regs, unsigned long
start, unsigned long sp)
regs-msr = MSR_USER;
#else
if (!is_32bit_task()) {
- unsigned long entry, toc;
+ unsigned long entry;
- /* start is a relocated pointer to the function descriptor for
-* the elf _start routine. The first entry in the function
-* descriptor is the entry address of _start and the second
-* entry is the TOC value we need to use.
-*/
- __get_user(entry, (unsigned long __user *)start);
- __get_user(toc, (unsigned long __user *)start+1);
+ if (is_elf2_task()) {
+ /* Look ma, no function descriptors! */
+ entry = start;
- /* Check whether the e_entry function descriptor entries
-* need to be relocated before we can use them.
-*/
- if (load_addr != 0) {
- entry += load_addr;
- toc += load_addr;
+ /*
+* Ulrich says:
+* The latest iteration of the ABI requires that when
+* calling a function (at its global entry point),
+* the caller must ensure r12 holds the entry point
+* address (so that the function can quickly
+* establish addressability).
+*/
+ regs-gpr[12] = start;
+ /* Make sure that's restored on entry to userspace. */
+ set_thread_flag(TIF_RESTOREALL);
+ } else {
+ unsigned long toc;
+
+ /* start is a relocated pointer to the function
+* descriptor for the elf _start routine. The first
+* entry in the function descriptor is the entry
+* address of _start and the second entry is the TOC
+* value we need to use.
+*/
+ __get_user(entry, (unsigned long __user *)start);
+ __get_user(toc, (unsigned long __user *)start+1);
+
+ /* Check whether the e_entry function descriptor entries
+* need to be relocated before we can use them.
+*/
+ if (load_addr != 0) {
+ entry += load_addr;
+ toc += load_addr;
+ }
+ regs-gpr[2] = toc;
}
regs-nip = entry;
- regs-gpr[2] = toc;
regs-msr = MSR_USER64;
} else {
regs-nip = start;
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/9] powerpc: ELF2 binaries signal handling
From: Rusty Russell ru...@rustcorp.com.au
For the ELFv2 ABI, the hander is the entry point, not a function descriptor.
We also need to set up r12, and fortunately the fast_exception_return
exit path restores r12 for us so nothing else is required.
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/kernel/signal_64.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index b3c6157..e66f67b 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -701,12 +701,6 @@ badframe:
int handle_rt_signal64(int signr, struct k_sigaction *ka, siginfo_t *info,
sigset_t *set, struct pt_regs *regs)
{
- /* Handler is *really* a pointer to the function descriptor for
-* the signal routine. The first entry in the function
-* descriptor is the entry address of signal and the second
-* entry is the TOC value we need to use.
-*/
- func_descr_t __user *funct_desc_ptr;
struct rt_sigframe __user *frame;
unsigned long newsp = 0;
long err = 0;
@@ -766,19 +760,32 @@ int handle_rt_signal64(int signr, struct k_sigaction *ka,
siginfo_t *info,
goto badframe;
regs-link = (unsigned long) frame-tramp[0];
}
- funct_desc_ptr = (func_descr_t __user *) ka-sa.sa_handler;
/* Allocate a dummy caller frame for the signal handler. */
newsp = ((unsigned long)frame) - __SIGNAL_FRAMESIZE;
err |= put_user(regs-gpr[1], (unsigned long __user *)newsp);
/* Set up regs so we return to the signal handler. */
- err |= get_user(regs-nip, funct_desc_ptr-entry);
+ if (is_elf2_task()) {
+ regs-nip = (unsigned long) ka-sa.sa_handler;
+ regs-gpr[12] = regs-nip;
+ } else {
+ /* Handler is *really* a pointer to the function descriptor for
+* the signal routine. The first entry in the function
+* descriptor is the entry address of signal and the second
+* entry is the TOC value we need to use.
+*/
+ func_descr_t __user *funct_desc_ptr =
+ (func_descr_t __user *) ka-sa.sa_handler;
+
+ err |= get_user(regs-nip, funct_desc_ptr-entry);
+ err |= get_user(regs-gpr[2], funct_desc_ptr-toc);
+ }
+
/* enter the signal handler in native-endian mode */
regs-msr = ~MSR_LE;
regs-msr |= (MSR_KERNEL MSR_LE);
regs-gpr[1] = newsp;
- err |= get_user(regs-gpr[2], funct_desc_ptr-toc);
regs-gpr[3] = signr;
regs-result = 0;
if (ka-sa.sa_flags SA_SIGINFO) {
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 9/9] powerpc: Add pseries_le_defconfig
Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/configs/pseries_le_defconfig | 352 ++ 1 file changed, 352 insertions(+) create mode 100644 arch/powerpc/configs/pseries_le_defconfig diff --git a/arch/powerpc/configs/pseries_le_defconfig b/arch/powerpc/configs/pseries_le_defconfig new file mode 100644 index 000..62771e0 --- /dev/null +++ b/arch/powerpc/configs/pseries_le_defconfig @@ -0,0 +1,352 @@ +CONFIG_PPC64=y +CONFIG_ALTIVEC=y +CONFIG_VSX=y +CONFIG_SMP=y +CONFIG_NR_CPUS=2048 +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_AUDIT=y +CONFIG_AUDITSYSCALL=y +CONFIG_IRQ_DOMAIN_DEBUG=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_DEVICE=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_CPUACCT=y +CONFIG_BLK_DEV_INITRD=y +# CONFIG_COMPAT_BRK is not set +CONFIG_PROFILING=y +CONFIG_OPROFILE=y +CONFIG_KPROBES=y +CONFIG_JUMP_LABEL=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_MODULE_SRCVERSION_ALL=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_PPC_SPLPAR=y +CONFIG_SCANLOG=m +CONFIG_PPC_SMLPAR=y +CONFIG_DTL=y +# CONFIG_PPC_PMAC is not set +CONFIG_RTAS_FLASH=m +CONFIG_IBMEBUS=y +CONFIG_HZ_100=y +CONFIG_BINFMT_MISC=m +CONFIG_PPC_TRANSACTIONAL_MEM=y +CONFIG_KEXEC=y +CONFIG_IRQ_ALL_CPUS=y +CONFIG_MEMORY_HOTPLUG=y +CONFIG_MEMORY_HOTREMOVE=y +CONFIG_CMA=y +CONFIG_PPC_64K_PAGES=y +CONFIG_PPC_SUBPAGE_PROT=y +CONFIG_SCHED_SMT=y +CONFIG_HOTPLUG_PCI=y +CONFIG_HOTPLUG_PCI_RPA=m +CONFIG_HOTPLUG_PCI_RPA_DLPAR=m +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_XFRM_USER=m +CONFIG_NET_KEY=m +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_NET_IPIP=y +CONFIG_SYN_COOKIES=y +CONFIG_INET_AH=m +CONFIG_INET_ESP=m +CONFIG_INET_IPCOMP=m +# CONFIG_IPV6 is not set +CONFIG_NETFILTER=y +CONFIG_NF_CONNTRACK=m +CONFIG_NF_CONNTRACK_EVENTS=y +CONFIG_NF_CT_PROTO_UDPLITE=m +CONFIG_NF_CONNTRACK_FTP=m +CONFIG_NF_CONNTRACK_IRC=m +CONFIG_NF_CONNTRACK_TFTP=m +CONFIG_NF_CT_NETLINK=m +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m +CONFIG_NETFILTER_XT_TARGET_CONNMARK=m +CONFIG_NETFILTER_XT_TARGET_MARK=m +CONFIG_NETFILTER_XT_TARGET_NFLOG=m +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m +CONFIG_NETFILTER_XT_TARGET_TCPMSS=m +CONFIG_NETFILTER_XT_MATCH_COMMENT=m +CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m +CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m +CONFIG_NETFILTER_XT_MATCH_CONNMARK=m +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m +CONFIG_NETFILTER_XT_MATCH_DCCP=m +CONFIG_NETFILTER_XT_MATCH_DSCP=m +CONFIG_NETFILTER_XT_MATCH_ESP=m +CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m +CONFIG_NETFILTER_XT_MATCH_HELPER=m +CONFIG_NETFILTER_XT_MATCH_IPRANGE=m +CONFIG_NETFILTER_XT_MATCH_LENGTH=m +CONFIG_NETFILTER_XT_MATCH_LIMIT=m +CONFIG_NETFILTER_XT_MATCH_MAC=m +CONFIG_NETFILTER_XT_MATCH_MARK=m +CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m +CONFIG_NETFILTER_XT_MATCH_OWNER=m +CONFIG_NETFILTER_XT_MATCH_POLICY=m +CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m +CONFIG_NETFILTER_XT_MATCH_QUOTA=m +CONFIG_NETFILTER_XT_MATCH_RATEEST=m +CONFIG_NETFILTER_XT_MATCH_REALM=m +CONFIG_NETFILTER_XT_MATCH_RECENT=m +CONFIG_NETFILTER_XT_MATCH_SCTP=m +CONFIG_NETFILTER_XT_MATCH_STATE=m +CONFIG_NETFILTER_XT_MATCH_STATISTIC=m +CONFIG_NETFILTER_XT_MATCH_STRING=m +CONFIG_NETFILTER_XT_MATCH_TCPMSS=m +CONFIG_NETFILTER_XT_MATCH_TIME=m +CONFIG_NETFILTER_XT_MATCH_U32=m +CONFIG_NF_CONNTRACK_IPV4=m +CONFIG_IP_NF_IPTABLES=m +CONFIG_IP_NF_MATCH_AH=m +CONFIG_IP_NF_MATCH_ECN=m +CONFIG_IP_NF_MATCH_TTL=m +CONFIG_IP_NF_FILTER=m +CONFIG_IP_NF_TARGET_REJECT=m +CONFIG_IP_NF_TARGET_ULOG=m +CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_PROC_DEVICETREE=y +CONFIG_PARPORT=m +CONFIG_PARPORT_PC=m +CONFIG_BLK_DEV_FD=m +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_NBD=m +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_SIZE=65536 +CONFIG_VIRTIO_BLK=m +CONFIG_IDE=y +CONFIG_BLK_DEV_IDECD=y +CONFIG_BLK_DEV_GENERIC=y +CONFIG_BLK_DEV_AMD74XX=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_ST=y +CONFIG_BLK_DEV_SR=y +CONFIG_BLK_DEV_SR_VENDOR=y +CONFIG_CHR_DEV_SG=y +CONFIG_SCSI_MULTI_LUN=y +CONFIG_SCSI_CONSTANTS=y +CONFIG_SCSI_FC_ATTRS=y +CONFIG_SCSI_CXGB3_ISCSI=m +CONFIG_SCSI_CXGB4_ISCSI=m +CONFIG_SCSI_BNX2_ISCSI=m +CONFIG_BE2ISCSI=m +CONFIG_SCSI_MPT2SAS=m +CONFIG_SCSI_IBMVSCSI=y +CONFIG_SCSI_IBMVFC=m +CONFIG_SCSI_SYM53C8XX_2=y +CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 +CONFIG_SCSI_IPR=y +CONFIG_SCSI_QLA_FC=m +CONFIG_SCSI_QLA_ISCSI=m +CONFIG_SCSI_LPFC=m +CONFIG_SCSI_VIRTIO=m +CONFIG_SCSI_DH=m +CONFIG_SCSI_DH_RDAC=m +CONFIG_SCSI_DH_ALUA=m +CONFIG_ATA=y +# CONFIG_ATA_SFF is not set +CONFIG_MD=y +CONFIG_BLK_DEV_MD=y +CONFIG_MD_LINEAR=y +CONFIG_MD_RAID0=y +CONFIG_MD_RAID1=y +CONFIG_MD_RAID10=m +CONFIG_MD_RAID456=m +CONFIG_MD_MULTIPATH=m +CONFIG_MD_FAULTY=m +CONFIG_BLK_DEV_DM=y +CONFIG_DM_CRYPT=m +CONFIG_DM_SNAPSHOT=m +CONFIG_DM_MIRROR=m +CONFIG_DM_ZERO=m +CONFIG_DM_MULTIPATH=m +CONFIG_DM_MULTIPATH_QL=m
[PATCH 1/9] powerpc/pseries: Fix endian issues in pseries EEH code
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c
b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 7fbc25b..ccb633e 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -189,8 +189,9 @@ static void *pseries_eeh_of_probe(struct device_node *dn,
void *flag)
struct eeh_dev *edev;
struct eeh_pe pe;
struct pci_dn *pdn = PCI_DN(dn);
- const u32 *class_code, *vendor_id, *device_id;
- const u32 *regs;
+ const __be32 *classp, *vendorp, *devicep;
+ u32 class_code;
+ const __be32 *regs;
u32 pcie_flags;
int enable = 0;
int ret;
@@ -201,22 +202,24 @@ static void *pseries_eeh_of_probe(struct device_node *dn,
void *flag)
return NULL;
/* Retrieve class/vendor/device IDs */
- class_code = of_get_property(dn, class-code, NULL);
- vendor_id = of_get_property(dn, vendor-id, NULL);
- device_id = of_get_property(dn, device-id, NULL);
+ classp = of_get_property(dn, class-code, NULL);
+ vendorp = of_get_property(dn, vendor-id, NULL);
+ devicep = of_get_property(dn, device-id, NULL);
/* Skip for bad OF node or PCI-ISA bridge */
- if (!class_code || !vendor_id || !device_id)
+ if (!classp || !vendorp || !devicep)
return NULL;
if (dn-type !strcmp(dn-type, isa))
return NULL;
+ class_code = of_read_number(classp, 1);
+
/*
* Update class code and mode of eeh device. We need
* correctly reflects that current device is root port
* or PCIe switch downstream port.
*/
- edev-class_code = *class_code;
+ edev-class_code = class_code;
edev-pcie_cap = pseries_eeh_find_cap(dn, PCI_CAP_ID_EXP);
edev-mode = 0xFF00;
if ((edev-class_code 8) == PCI_CLASS_BRIDGE_PCI) {
@@ -243,12 +246,12 @@ static void *pseries_eeh_of_probe(struct device_node *dn,
void *flag)
/* Initialize the fake PE */
memset(pe, 0, sizeof(struct eeh_pe));
pe.phb = edev-phb;
- pe.config_addr = regs[0];
+ pe.config_addr = of_read_number(regs, 1);
/* Enable EEH on the device */
ret = eeh_ops-set_option(pe, EEH_OPT_ENABLE);
if (!ret) {
- edev-config_addr = regs[0];
+ edev-config_addr = of_read_number(regs, 1);
/* Retrieve PE address */
edev-pe_config_addr = eeh_ops-get_pe_addr(pe);
pe.addr = edev-pe_config_addr;
--
1.8.3.2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 4/9] powerpc: Set eflags correctly for ELF ABIv2 core dumps.
From: Rusty Russell ru...@rustcorp.com.au We leave it at zero (though it could be 1) for old tasks. Signed-off-by: Rusty Russell ru...@rustcorp.com.au Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/include/asm/elf.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/include/asm/elf.h b/arch/powerpc/include/asm/elf.h index 6d0e236..935b5e7 100644 --- a/arch/powerpc/include/asm/elf.h +++ b/arch/powerpc/include/asm/elf.h @@ -31,6 +31,8 @@ extern unsigned long randomize_et_dyn(unsigned long base); #define ELF_ET_DYN_BASE(randomize_et_dyn(0x2000)) +#define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0) + /* * Our registers are always unsigned longs, whether we're a 32 bit * process or 64 bit, on either a 64 bit or 32 bit kernel. -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/9] pseries: Add H_SET_MODE to change exception endianness
On little endian builds call H_SET_MODE so exceptions have the
correct endianness. We need to reset the endian during kexec
so do that in the MMU hashtable clear callback.
Signed-off-by: Anton Blanchard an...@samba.org
---
arch/powerpc/include/asm/hvcall.h | 2 ++
arch/powerpc/include/asm/plpar_wrappers.h | 26 +++
arch/powerpc/platforms/pseries/lpar.c | 17 +
arch/powerpc/platforms/pseries/setup.c| 42 +++
4 files changed, 87 insertions(+)
diff --git a/arch/powerpc/include/asm/hvcall.h
b/arch/powerpc/include/asm/hvcall.h
index 0c7f2bf..d8b600b 100644
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -403,6 +403,8 @@ static inline unsigned long cmo_get_page_size(void)
extern long pSeries_enable_reloc_on_exc(void);
extern long pSeries_disable_reloc_on_exc(void);
+extern long pseries_big_endian_exceptions(void);
+
#else
#define pSeries_enable_reloc_on_exc() do {} while (0)
diff --git a/arch/powerpc/include/asm/plpar_wrappers.h
b/arch/powerpc/include/asm/plpar_wrappers.h
index a63b045..12c32c5 100644
--- a/arch/powerpc/include/asm/plpar_wrappers.h
+++ b/arch/powerpc/include/asm/plpar_wrappers.h
@@ -287,6 +287,32 @@ static inline long disable_reloc_on_exceptions(void) {
return plpar_set_mode(0, 3, 0, 0);
}
+/*
+ * Take exceptions in big endian mode on this partition
+ *
+ * Note: this call has a partition wide scope and can take a while to complete.
+ * If it returns H_LONG_BUSY_* it should be retried periodically until it
+ * returns H_SUCCESS.
+ */
+static inline long enable_big_endian_exceptions(void)
+{
+ /* mflags = 0: big endian exceptions */
+ return plpar_set_mode(0, 4, 0, 0);
+}
+
+/*
+ * Take exceptions in little endian mode on this partition
+ *
+ * Note: this call has a partition wide scope and can take a while to complete.
+ * If it returns H_LONG_BUSY_* it should be retried periodically until it
+ * returns H_SUCCESS.
+ */
+static inline long enable_little_endian_exceptions(void)
+{
+ /* mflags = 1: little endian exceptions */
+ return plpar_set_mode(1, 4, 0, 0);
+}
+
static inline long plapr_set_ciabr(unsigned long ciabr)
{
return plpar_set_mode(0, 1, ciabr, 0);
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powerpc/platforms/pseries/lpar.c
index 356bc75..4fca3de 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -245,6 +245,23 @@ static void pSeries_lpar_hptab_clear(void)
(ptes[j].pteh), (ptes[j].ptel));
}
}
+
+#ifdef __LITTLE_ENDIAN__
+ /* Reset exceptions to big endian */
+ if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
+ long rc;
+
+ rc = pseries_big_endian_exceptions();
+ /*
+* At this point it is unlikely panic() will get anything
+* out to the user, but at least this will stop us from
+* continuing on further and creating an even more
+* difficult to debug situation.
+*/
+ if (rc)
+ panic(Could not enable big endian exceptions);
+ }
+#endif
}
/*
diff --git a/arch/powerpc/platforms/pseries/setup.c
b/arch/powerpc/platforms/pseries/setup.c
index 1f97e2b..c1f1908 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -442,6 +442,32 @@ static void pSeries_machine_kexec(struct kimage *image)
}
#endif
+#ifdef __LITTLE_ENDIAN__
+long pseries_big_endian_exceptions(void)
+{
+ long rc;
+
+ while (1) {
+ rc = enable_big_endian_exceptions();
+ if (!H_IS_LONG_BUSY(rc))
+ return rc;
+ mdelay(get_longbusy_msecs(rc));
+ }
+}
+
+static long pseries_little_endian_exceptions(void)
+{
+ long rc;
+
+ while (1) {
+ rc = enable_little_endian_exceptions();
+ if (!H_IS_LONG_BUSY(rc))
+ return rc;
+ mdelay(get_longbusy_msecs(rc));
+ }
+}
+#endif
+
static void __init pSeries_setup_arch(void)
{
panic_timeout = 10;
@@ -698,6 +724,22 @@ static int __init pSeries_probe(void)
/* Now try to figure out if we are running on LPAR */
of_scan_flat_dt(pseries_probe_fw_features, NULL);
+#ifdef __LITTLE_ENDIAN__
+ if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
+ long rc;
+ /*
+* Tell the hypervisor that we want our exceptions to
+* be taken in little endian mode. If this fails we don't
+* want to use BUG() because it will trigger an exception.
+*/
+ rc = pseries_little_endian_exceptions();
+ if (rc) {
+ ppc_md.progress(H_SET_MODE LE exception fail, 0);
+
[PATCH 7/9] powerpc: Don't use ELFv2 ABI to build the kernel
From: Alistair Popple alist...@popple.id.au The kernel doesn't build correctly using the ELFv2 ABI. This patch ensures that the ELFv1 ABI is used when building a kernel with an ELFv2 enabled compiler. Signed-off-by: Alistair Popple alist...@popple.id.au Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 607acf5..8a24636 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -111,6 +111,7 @@ endif endif CFLAGS-$(CONFIG_PPC64) := -mtraceback=no -mcall-aixdesc +CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv1) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mcmodel=medium,-mminimal-toc) CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mno-pointers-to-nested-functions) CFLAGS-$(CONFIG_PPC32) := -ffixed-r2 $(MULTIPLEWORD) -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 8/9] powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.
With the little endian support merged, we can add the CONFIG_CPU_LITTLE_ENDIAN kernel config option. Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/platforms/Kconfig.cputype | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype index c2a566f..132f872 100644 --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -403,3 +403,14 @@ config PPC_DOORBELL default n endmenu + +config CPU_LITTLE_ENDIAN + bool Build little endian kernel + default n + help + This option selects whether a big endian or little endian kernel will + be built. + + Note that if cross compiling a little endian kernel, + CROSS_COMPILE must point to a toolchain capable of targeting + little endian powerpc. -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
BUG: Patch Convert some mftb/mftbu into mfspr breaks MPC885
Scott, The patch Convert some mftb/mftbu into mfspr (beb2dc0a7a84be003ce54e98b95d65cc66e6e536 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/powerpc/include/asm/reg.h?id=beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885. The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to read TBU with mfspr. Reverting the patch solves the issue. What's the prefered way to fix this ? Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc/CoreNet64: compile with CONFIG_E{5,6}500_CPU well
On Wed, 2013-11-20 at 16:35 +0800, Tiejun Chen wrote:
CONFIG_ALTIVEC is always enabled for CoreNet64.
In the defconfig perhaps, but this isn't a generally true statement.
And if we select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec and Spe options not allowed with
e500mc64, so :
Sigh.
CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/lib/Makefile |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 95a20e1..641a77d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,5 +40,8 @@ obj-y += code-patching.o
obj-y+= feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
+# Altivec and Spe options not allowed with e500mc64 in GCC.
+ifeq ($(call cc-option-yn,-mcpu=e500mc64),n)
obj-$(CONFIG_ALTIVEC)+= xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec -mabi=altivec
+endif
This does not seem like the right fix. What if GCC supports both
-mcpu=e500mc64 and -mcpu=e6500, and we're using the latter? Or for that
matter, if we're using -mcpu=whatever-ibm-chip-has-this?
Plus, wouldn't you need to do something to prevent code in that file
from being called?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BUG: Patch Convert some mftb/mftbu into mfspr breaks MPC885
On Wed, 2013-11-20 at 10:37 +0100, leroy christophe wrote: Scott, The patch Convert some mftb/mftbu into mfspr (beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885. The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to read TBU with mfspr. Reverting the patch solves the issue. What's the prefered way to fix this ? I guess we need to add an ifdef. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
On Tue, 2013-11-19 at 10:47 +0530, Bharat Bhushan wrote: From: Bharat Bhushan bharat.bhus...@freescale.com PAMU (FSL IOMMU) has a concept of primary window and subwindows. Primary window corresponds to the complete guest iova address space (including MSI space), with respect to IOMMU_API this is termed as geometry. IOVA Base of subwindow is determined from the number of subwindows (configurable using iommu API). MSI I/O page must be within the geometry and maximum supported subwindows, so MSI IO-page is setup just after guest memory iova space. So patch 1/9-4/9(inclusive) are for defining the interface to get: - Number of MSI regions (which is number of MSI banks for powerpc) - MSI-region address range: Physical page which have the address/addresses used for generating MSI interrupt and size of the page. Patch 5/9-7/9(inclusive) is defining the interface of setting up MSI iova-base for a msi region(bank) for a device. so that when msi-message will be composed then this configured iova will be used. Earlier we were using iommu interface for getting the configured iova which was not currect and Alex Williamson suggeested this type of interface. patch 8/9 moves some common functions in a separate file so that these can be used by FSL_PAMU implementation (next patch uses this). These will be used later for iommu-none implementation. I believe we can do more of this but will take step by step. Finally last patch actually adds the support for FSL-PAMU :) Patches 1-3: msi_get_region needs to return an error an error (probably -EINVAL) if called on a path where there's no backend implementation. Otherwise the caller doesn't know that the data in the region pointer isn't valid. Patches 56: same as above for msi_set_iova, return an error if no backend implementation. Patch 7: Why does fsl_msi_del_iova_device bother to return anything if it's always zero? Return -ENODEV when not found? Patch 9: vfio_handle_get_attr() passes random kernel data back to userspace in the event of iommu_domain_get_attr() error. vfio_handle_set_attr(): I don't see any data validation happening, is iommu_domain_set_attr() really that safe? For both of those, drop the pr_err on unknown attribute, it's sufficient to return error. Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie. each vfio user has $COUNT regions at their disposal exclusively)? Thanks, Alex v1-v2 - Added interface for setting msi iova for a msi region for a device. Earlier I added iommu interface for same but as per comment that is removed and now created a direct interface between vfio and msi. - Incorporated review comments (details is in individual patch) Bharat Bhushan (9): pci:msi: add weak function for returning msi region info pci: msi: expose msi region information functions powerpc: pci: Add arch specific msi region interface powerpc: msi: Extend the msi region interface to get info from fsl_msi pci/msi: interface to set an iova for a msi region powerpc: pci: Extend msi iova page setup to arch specific pci: msi: Extend msi iova setting interface to powerpc arch vfio: moving some functions in common file vfio pci: Add vfio iommu implementation for FSL_PAMU arch/powerpc/include/asm/machdep.h | 10 + arch/powerpc/kernel/msi.c | 28 + arch/powerpc/sysdev/fsl_msi.c | 132 +- arch/powerpc/sysdev/fsl_msi.h | 25 +- drivers/pci/msi.c | 35 ++ drivers/vfio/Kconfig |6 + drivers/vfio/Makefile |5 +- drivers/vfio/vfio_iommu_common.c | 227 drivers/vfio/vfio_iommu_common.h | 27 + drivers/vfio/vfio_iommu_fsl_pamu.c | 1003 drivers/vfio/vfio_iommu_type1.c| 206 + include/linux/msi.h| 14 + include/linux/pci.h| 21 + include/uapi/linux/vfio.h | 100 14 files changed, 1623 insertions(+), 216 deletions(-) create mode 100644 drivers/vfio/vfio_iommu_common.c create mode 100644 drivers/vfio/vfio_iommu_common.h create mode 100644 drivers/vfio/vfio_iommu_fsl_pamu.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc/CoreNet64: compile with CONFIG_E{5, 6}500_CPU well
On Nov 20, 2013, at 10:41 AM, Scott Wood scottw...@freescale.com wrote:
On Wed, 2013-11-20 at 16:35 +0800, Tiejun Chen wrote:
CONFIG_ALTIVEC is always enabled for CoreNet64.
In the defconfig perhaps, but this isn't a generally true statement.
And if we select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64
into $CFLAGS. But Altivec and Spe options not allowed with
e500mc64, so :
Sigh.
CC arch/powerpc/lib/xor_vmx.o
arch/powerpc/lib/xor_vmx.c:1:0: error: AltiVec not supported in this target
make[1]: *** [arch/powerpc/lib/xor_vmx.o] Error 1
make: *** [arch/powerpc/lib] Error 2
Signed-off-by: Tiejun Chen tiejun.c...@windriver.com
---
arch/powerpc/lib/Makefile |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 95a20e1..641a77d 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -40,5 +40,8 @@ obj-y += code-patching.o
obj-y+= feature-fixups.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
+# Altivec and Spe options not allowed with e500mc64 in GCC.
+ifeq ($(call cc-option-yn,-mcpu=e500mc64),n)
obj-$(CONFIG_ALTIVEC)+= xor_vmx.o
CFLAGS_xor_vmx.o += -maltivec -mabi=altivec
+endif
This does not seem like the right fix. What if GCC supports both
-mcpu=e500mc64 and -mcpu=e6500, and we're using the latter? Or for that
matter, if we're using -mcpu=whatever-ibm-chip-has-this?
Plus, wouldn't you need to do something to prevent code in that file
from being called?
-Scott
Why does -mcpu=e500mc64 get you spe enabled? It shouldn’t as no e500mc or
greater part has spe. Can you try using -mno-spe -maltivec?
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Wrong DWARF CFI in the kernel vdso for little-endian / ELFv2
From: Ulrich Weigand ulrich.weig...@de.ibm.com I've finally tracked down why my CR signal-unwind test case still fails on little-endian. The problem turned to be that the kernel installs a signal trampoline in the vDSO, and provides a DWARF CFI record for that trampoline. This CFI describes the save location for CR: rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) which is correct for big-endian, but points to the wrong word on little-endian. This is wrong no matter which ABI. In addition, for the ELFv2 ABI, we should not only provide a CFI record for register 70 (cr2), but for all CR fields separately. Strictly speaking, I guess this would mean providing two separate vDSO images, one for ELFv1 processes and one for ELFv2 processes (or maybe playing some tricks with conditional DWARF expressions). However, having CFI records for the other CR fields in ELFv1 is not actually wrong, they just will be ignored. So it seems the simplest fix would be just to always provide CFI for all the fields. Signed-off-by: Ulrich Weigand ulrich.weig...@de.ibm.com Signed-off-by: Anton Blanchard an...@samba.org --- arch/powerpc/kernel/vdso64/sigtramp.S | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/vdso64/sigtramp.S b/arch/powerpc/kernel/vdso64/sigtramp.S index 45ea281..542c6f42 100644 --- a/arch/powerpc/kernel/vdso64/sigtramp.S +++ b/arch/powerpc/kernel/vdso64/sigtramp.S @@ -142,6 +142,13 @@ V_FUNCTION_END(__kernel_sigtramp_rt64) /* Size of CR reg in DWARF unwind info. */ #define CRSIZE 4 +/* Offset of CR reg within a full word. */ +#ifdef __LITTLE_ENDIAN__ +#define CROFF 0 +#else +#define CROFF (RSIZE - CRSIZE) +#endif + /* This is the offset of the VMX reg pointer. */ #define VREGS 48*RSIZE+33*8 @@ -181,7 +188,14 @@ V_FUNCTION_END(__kernel_sigtramp_rt64) rsave (31, 31*RSIZE); \ rsave (67, 32*RSIZE);/* ap, used as temp for nip */ \ rsave (65, 36*RSIZE);/* lr */ \ - rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */ + rsave (68, 38*RSIZE + CROFF);/* cr fields */ \ + rsave (69, 38*RSIZE + CROFF); \ + rsave (70, 38*RSIZE + CROFF); \ + rsave (71, 38*RSIZE + CROFF); \ + rsave (72, 38*RSIZE + CROFF); \ + rsave (73, 38*RSIZE + CROFF); \ + rsave (74, 38*RSIZE + CROFF); \ + rsave (75, 38*RSIZE + CROFF) /* Describe where the FP regs are saved. */ #define EH_FRAME_FP \ -- 1.8.3.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] KVM: PPC: vfio kvm device: support spapr tce
On Wed, 2013-11-20 at 16:18 +1100, Alexey Kardashevskiy wrote:
In addition to the external VFIO user API, a VFIO KVM device
has been introduced recently.
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
identifier. LIOBNs are made up and linked to IOMMU groups by the user
space. In order to accelerate IOMMU operations in the KVM, we need
to tell KVM the information about LIOBN-to-group mapping.
For that, a new KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN parameter
is added. It accepts a pair of a VFIO group fd and LIOBN.
This also adds a new kvm_vfio_find_group_by_liobn() function which
receives kvm struct, LIOBN and a callback. As it increases the IOMMU
group use counter, the KVMr is required to pass a callback which
called when the VFIO group is about to be removed VFIO-KVM tracking so
the KVM is able to call iommu_group_put() to release the IOMMU group.
The KVM uses kvm_vfio_find_group_by_liobn() once per KVM run and caches
the result in kvm_arch. iommu_group_put() for all groups will be called
when KVM finishes (in the SPAPR TCE in KVM enablement patch).
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* total rework
* added a release callback into kvm_vfio_find_group_by_liobn so now
the user of the API can get a notification if the group is about to
disappear
---
Documentation/virtual/kvm/devices/vfio.txt | 19 -
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/Makefile | 3 +
include/linux/kvm_host.h | 18 +
include/uapi/linux/kvm.h | 7 ++
virt/kvm/vfio.c| 116
-
6 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt
b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..7ecb3b2 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -16,7 +16,22 @@ Groups:
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
+ KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: sets a liobn for a VFIO group
+ kvm_device_attr.addr points to a struct:
+ struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __u32 fd;
fds are signed, __s32
+ __u32 liobn;
+ };
+ where
+ @argsz is a struct size;
+ @fd is a file descriptor for a VFIO group;
+ @liobn is a logical bus id to be associated with the group.
-For each, kvm_device_attr.addr points to an int32_t file descriptor
-for the VFIO group.
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 61b3535..d1b7f64 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU
+ select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+ $(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 88ff96a..1d2ad5e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1112,5 +1112,23 @@ static inline bool
kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
}
#endif /* CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT */
+
+typedef void (*kvm_vfio_release_group_callback)(struct kvm *kvm,
+ unsigned long liobn);
liobn was said to be __u32 in kvm_vfio_spapr_tce_liobn above, here it's
unsigned long?
+
+#if defined(CONFIG_KVM_VFIO) defined(CONFIG_SPAPR_TCE_IOMMU)
+
+extern struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, kvm_vfio_release_group_callback cb);
+
+#else
+
+static inline struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm
*kvm,
+ unsigned long liobn, ikvm_vfio_release_group_callback cb)
+{
+ return NULL;
+}
+#endif /* CONFIG_KVM_VFIO
Re: [PATCH v2] offb: make the screen properties endian safe
On Thu, 2013-10-31 at 10:36 +0100, Cédric Le Goater wrote: The screen properties : depth, width, height, linebytes need to be converted to the host endian order when read from the device tree. Signed-off-by: Cédric Le Goater c...@fr.ibm.com --- Did you actually test that ? IE, using emulated VGA in qemu for example ? I'm asking because there are a few interesting nits here... - fbdev *generally* assume native endian framebuffer, but of course under qemu today, the adapter will use a big endian frame buffer aperture. You can compile in support for foreign endian but I don't know how that actually works. - The setcolreg fix ... the value is used 2 lines above your endian swap, is that correct ? Cheers Ben. Changes in v2: - replaced be32_to_cpu() by be32_to_cpup() - fixed setcolreg ops drivers/video/offb.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/video/offb.c b/drivers/video/offb.c index 0c4f343..68e8415 100644 --- a/drivers/video/offb.c +++ b/drivers/video/offb.c @@ -120,7 +120,7 @@ static int offb_setcolreg(u_int regno, u_int red, u_int green, u_int blue, mask = info-var.transp.offset; value |= mask; } - pal[regno] = value; + pal[regno] = cpu_to_be32(value); return 0; } @@ -536,7 +536,7 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node) unsigned int flags, rsize, addr_prop = 0; unsigned long max_size = 0; u64 rstart, address = OF_BAD_ADDR; - const u32 *pp, *addrp, *up; + const __be32 *pp, *addrp, *up; u64 asize; int foreign_endian = 0; @@ -552,25 +552,25 @@ static void __init offb_init_nodriver(struct device_node *dp, int no_real_node) if (pp == NULL) pp = of_get_property(dp, depth, len); if (pp len == sizeof(u32)) - depth = *pp; + depth = be32_to_cpup(pp); pp = of_get_property(dp, linux,bootx-width, len); if (pp == NULL) pp = of_get_property(dp, width, len); if (pp len == sizeof(u32)) - width = *pp; + width = be32_to_cpup(pp); pp = of_get_property(dp, linux,bootx-height, len); if (pp == NULL) pp = of_get_property(dp, height, len); if (pp len == sizeof(u32)) - height = *pp; + height = be32_to_cpup(pp); pp = of_get_property(dp, linux,bootx-linebytes, len); if (pp == NULL) pp = of_get_property(dp, linebytes, len); if (pp len == sizeof(u32) (*pp != 0xu)) - pitch = *pp; + pitch = be32_to_cpup(pp); else pitch = width * ((depth + 7) / 8); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! With my previous pull request I mentioned some remaining Little Endian patches, notably support for our new ABI, which I was sitting on making sure it was all finalized. The toolchain folks confirmed it now, the new ABI is stable and merged with gcc, so we are all good. Oh and we actually missed the actual Kconfig switch for LE so here it is, along with a couple more bug fixes. I have more fixes but not related to LE so I'll send them as a separate pull request tomorrow, let's get this one out of the way. Note that this supports running user space binaries using the new ABI, but the kernel itself still needs to be built with the old one. We'll bring fixes for that after -rc1. Here's Anton log that goes with this series: This patch series adds support for the new ABI, LPAR support for H_SET_MODE and finally adds a kconfig option and defconfig. ABIv2 support was recently committed to binutils and gcc, and should be merged into glibc soon. There are a number of very nice improvements including the removal of function descriptors. Rusty's kernel patches allow binaries of either ABI to work, easing the transition. Cheers, Ben. The following changes since commit 0c4888ef1d8a8b82c29075ce7e257ff795af15c7: powerpc: Fix fatal SLB miss when restoring PPR (2013-11-06 14:13:53 +1100) 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 280270828f108be56f0c486def58acabb070244f: powerpc: Wrong DWARF CFI in the kernel vdso for little-endian / ELFv2 (2013-11-21 09:19:23 +1100) Alistair Popple (1): powerpc: Don't use ELFv2 ABI to build the kernel Anton Blanchard (4): powerpc/pseries: Fix endian issues in pseries EEH code pseries: Add H_SET_MODE to change exception endianness powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option. powerpc: Add pseries_le_defconfig Rusty Russell (4): powerpc: Add TIF_ELF2ABI flag. powerpc: Set eflags correctly for ELF ABIv2 core dumps. powerpc: ELF2 binaries launched directly. powerpc: ELF2 binaries signal handling Ulrich Weigand (1): powerpc: Wrong DWARF CFI in the kernel vdso for little-endian / ELFv2 arch/powerpc/Makefile| 1 + arch/powerpc/configs/pseries_le_defconfig| 352 +++ arch/powerpc/include/asm/elf.h | 4 + arch/powerpc/include/asm/hvcall.h| 2 + arch/powerpc/include/asm/plpar_wrappers.h| 26 ++ arch/powerpc/include/asm/thread_info.h | 9 + arch/powerpc/kernel/process.c| 50 ++-- arch/powerpc/kernel/signal_64.c | 25 +- arch/powerpc/kernel/vdso64/sigtramp.S| 16 +- arch/powerpc/platforms/Kconfig.cputype | 11 + arch/powerpc/platforms/pseries/eeh_pseries.c | 21 +- arch/powerpc/platforms/pseries/lpar.c| 17 ++ arch/powerpc/platforms/pseries/setup.c | 42 13 files changed, 542 insertions(+), 34 deletions(-) create mode 100644 arch/powerpc/configs/pseries_le_defconfig ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
On Wed, Nov 20, 2013 at 12:28:02PM +1100, Benjamin Herrenschmidt wrote: On Tue, 2013-11-19 at 16:11 +0800, Li Zhong wrote: I encountered following issue: [0.283035] ibmvscsi 3015: couldn't initialize event pool [5.688822] ibmvscsi: probe of 3015 failed with error -1 which prevents the storage from being recognized, and the machine from booting. After some digging, it seems that it is caused by commit 4886c399da as dma_mask pointer in viodev-dev is not set, so in dma_set_mask_and_coherent(), dma_set_coherent_mask() is not called because dma_set_mask(), which is dma_set_mask_pSeriesLP() returned EIO. While before the commit, dma_set_coherent_mask() is always called. I tried to replace dma_set_mask_and_coherent() with dma_coerce_mask_and_coherent(), and the machine could boot again. But I'm not sure whether this is the correct fix... Russell, care to chime in ? I can't make sense of the semantics... The original commit was fairly clear: Replace the following sequence: dma_set_mask(dev, mask); dma_set_coherent_mask(dev, mask); with a call to the new helper dma_set_mask_and_coherent(). It all makes sense so far ... but doesn't work for some odd reason, and the fix uses a function whose name doesn't make much sense to me ... what is the difference between setting and coercing the mask ? And why doe replacing two set with a set both doesn't work and require a coerce ? I'm asking because I'm worried about breakage elsewhere... I'd expect that the reason it doesn't work is that the dma_set_mask() is failing, which means we don't go on to set the coherent mask. Li Zong's patch works around the issue of a failing dma_set_mask(), but as I've already said elsewhere, the real fix is to get whatever created the struct device to initialise the dev-dma_mask with a bus default. Using dma_coerce_xxx() merely makes the problem go away papering over the issue - it's fine to do it this way, but someone should still fix the broken code creating these devices... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
On Wed, 2013-11-20 at 23:23 +, Russell King - ARM Linux wrote: Li Zong's patch works around the issue of a failing dma_set_mask(), but as I've already said elsewhere, the real fix is to get whatever created the struct device to initialise the dev-dma_mask with a bus default. Using dma_coerce_xxx() merely makes the problem go away papering over the issue - it's fine to do it this way, but someone should still fix the broken code creating these devices... Ok, they are created by the vio bus core, so it should be doing the job here of setting the dma_mask pointer to a proper value. Li, can you take care of that ? Look at other bus types we have in there such as the macio bus etc... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
On Thu, Nov 21, 2013 at 11:01:42AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2013-11-20 at 23:23 +, Russell King - ARM Linux wrote: Li Zong's patch works around the issue of a failing dma_set_mask(), but as I've already said elsewhere, the real fix is to get whatever created the struct device to initialise the dev-dma_mask with a bus default. Using dma_coerce_xxx() merely makes the problem go away papering over the issue - it's fine to do it this way, but someone should still fix the broken code creating these devices... Ok, they are created by the vio bus core, so it should be doing the job here of setting the dma_mask pointer to a proper value. Li, can you take care of that ? Look at other bus types we have in there such as the macio bus etc... Oh, hang on a moment, this is the bus code. In which case, the question becomes: do vio devices ever need to have a separate streaming DMA mask from a coherent DMA mask? If not, then something like the following is what's needed here, and I should've never have used dma_set_mask_and_coherent(). dma_set_mask_and_coherent() (and the other dma_set_mask() functions) are really supposed to be used by drivers only. arch/powerpc/kernel/vio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f621a..d771778f398e 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,8 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(viodev-dev, DMA_BIT_MASK(64)); + viodev-dev.coherent_dma_mask = DMA_BIT_MASK(64); + viodev-dev.dma_mask = viodev-dev.coherent_dma_mask; } /* register with generic device framework */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
On Thu, 2013-11-21 at 00:08 +, Russell King - ARM Linux wrote: On Thu, Nov 21, 2013 at 11:01:42AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2013-11-20 at 23:23 +, Russell King - ARM Linux wrote: Li Zong's patch works around the issue of a failing dma_set_mask(), but as I've already said elsewhere, the real fix is to get whatever created the struct device to initialise the dev-dma_mask with a bus default. Using dma_coerce_xxx() merely makes the problem go away papering over the issue - it's fine to do it this way, but someone should still fix the broken code creating these devices... Ok, they are created by the vio bus core, so it should be doing the job here of setting the dma_mask pointer to a proper value. Li, can you take care of that ? Look at other bus types we have in there such as the macio bus etc... Oh, hang on a moment, this is the bus code. In which case, the question becomes: do vio devices ever need to have a separate streaming DMA mask from a coherent DMA mask? If not, then something like the following is what's needed here, and I should've never have used dma_set_mask_and_coherent(). No, a single mask. dma_set_mask_and_coherent() (and the other dma_set_mask() functions) are really supposed to be used by drivers only. arch/powerpc/kernel/vio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f621a..d771778f398e 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,8 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(viodev-dev, DMA_BIT_MASK(64)); + viodev-dev.coherent_dma_mask = DMA_BIT_MASK(64); + viodev-dev.dma_mask = viodev-dev.coherent_dma_mask; } /* register with generic device framework */ Right that's exactly what I had in mind. Li, can you test this please ? The previous fix using dma_coerce_mask_and_coherent() is already on its way to Linus, so we'll rework the above patch to undo it but for now please test. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Wed, 2013-11-20 at 10:54 +0800, Liu Gang wrote: On Tue, 2013-11-19 at 16:51 -0600, Scott Wood wrote: @@ -71,6 +71,7 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR); + mpc8xxx_gc-data = in_be32(mm-regs + GPIO_DIR); return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio); } It seems odd to update -data in a function that's supposed to be reading things... Perhaps it would be better to keep -data in a good state from the beginning. -Scott Yes, keeping the -data in a good state from the beginning will be better. But this will need more code in different functions to cover all the scenarios. First, we should check the direct of the pin in the function mpc8xxx_gpio_set, and clean the input bit in -data after setting operation. For userspace value setting, it looks like gpiolib blocks the write if the pin if FLAG_IS_OUT is set. This suggests that this is an error condition for other uses as well. Though, I notice that mpc8xxx_gpio_dir_out() calls gpio_set() before actually changing the direction. So it may be useful to avoid races where the wrong value is output briefly after the direction is changed (especially in open drain situations, where the signal could have a meaningful default even before we begin outputting). But that raises the question of how you'd do that from userspace, and it also renders the to-be-output value as write-only data (until the direction is actually changed), since a readback would get the input value instead. So maybe it's better to eliminate the effects of the -data to the input pins when reading the status, regardless of the possible changes of the pins and the data. Do you think so? Perhaps, but that doesn't require you to modify -data in the get() function. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Since you pulled my previous one in less than 20mn (the LE stuff), there's no point waiting for tomorrow for these fixes I mentioned earlier so here they are. This is a small collection of random bug fixes and a few improvements of Oops output which I deemed valuable enough to include as well. The fixes are essentially recent build breakage and regressions, and a couple of older bugs such as the DTL log duplication, the EEH issue with PCI_COMMAND_MASTER and the problem with small contexts passed to get/set_context with VSX enabled. Cheers, Ben. The following changes since commit b4789b8e6be3151a955ade74872822f30e8cd914: aacraid: prevent invalid pointer dereference (2013-11-19 16:27:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to c13f20ac48328b05cd3b8c19e31ed6c132b44b42: powerpc/signals: Mark VSX not saved with small contexts (2013-11-21 10:33:45 +1100) Aneesh Kumar K.V (1): powerpc: booke: Fix build failures Anton Blanchard (5): powerpc: Print DAR and DSISR on machine check oopses powerpc: Remove a few lines of oops output powerpc/pseries: Duplicate dtl entries sometimes sent to userspace powerpc: Only print PACATMSCRATCH in oops when TM is active powerpc: ppc64 address space capped at 32TB, mmap randomisation disabled Gavin Shan (2): powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges powerpc/eeh: More accurate log Heiko Carstens (1): powerpc: Fix __get_user_pages_fast() irq handling Li Zhong (1): powerpc/vio: Fix a dma_mask issue of vio Michael Ellerman (2): powerpc: Make cpu_to_chip_id() available when SMP=n powerpc/pseries: Fix SMP=n build of rng.c Michael Neuling (1): powerpc/signals: Mark VSX not saved with small contexts arch/powerpc/include/asm/smp.h| 2 +- arch/powerpc/kernel/eeh.c | 9 + arch/powerpc/kernel/eeh_event.c | 9 +++-- arch/powerpc/kernel/process.c | 21 +++-- arch/powerpc/kernel/prom.c| 20 arch/powerpc/kernel/signal_32.c | 10 +- arch/powerpc/kernel/smp.c | 16 arch/powerpc/kernel/time.c| 4 ++-- arch/powerpc/kernel/vio.c | 2 +- arch/powerpc/mm/gup.c | 5 +++-- arch/powerpc/mm/slice.c | 2 +- arch/powerpc/platforms/powernv/rng.c | 1 + arch/powerpc/platforms/pseries/rng.c | 1 + arch/powerpc/platforms/wsp/chroma.c | 1 + arch/powerpc/platforms/wsp/h8.c | 1 + arch/powerpc/platforms/wsp/ics.c | 2 ++ arch/powerpc/platforms/wsp/opb_pic.c | 2 ++ arch/powerpc/platforms/wsp/psr2.c | 1 + arch/powerpc/platforms/wsp/scom_wsp.c | 1 + arch/powerpc/platforms/wsp/wsp.c | 1 + 20 files changed, 75 insertions(+), 36 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] KVM: PPC: vfio kvm device: support spapr tce
On 11/21/2013 07:57 AM, Alex Williamson wrote:
On Wed, 2013-11-20 at 16:18 +1100, Alexey Kardashevskiy wrote:
In addition to the external VFIO user API, a VFIO KVM device
has been introduced recently.
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
identifier. LIOBNs are made up and linked to IOMMU groups by the user
space. In order to accelerate IOMMU operations in the KVM, we need
to tell KVM the information about LIOBN-to-group mapping.
For that, a new KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN parameter
is added. It accepts a pair of a VFIO group fd and LIOBN.
This also adds a new kvm_vfio_find_group_by_liobn() function which
receives kvm struct, LIOBN and a callback. As it increases the IOMMU
group use counter, the KVMr is required to pass a callback which
called when the VFIO group is about to be removed VFIO-KVM tracking so
the KVM is able to call iommu_group_put() to release the IOMMU group.
The KVM uses kvm_vfio_find_group_by_liobn() once per KVM run and caches
the result in kvm_arch. iommu_group_put() for all groups will be called
when KVM finishes (in the SPAPR TCE in KVM enablement patch).
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* total rework
* added a release callback into kvm_vfio_find_group_by_liobn so now
the user of the API can get a notification if the group is about to
disappear
---
Documentation/virtual/kvm/devices/vfio.txt | 19 -
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/Makefile | 3 +
include/linux/kvm_host.h | 18 +
include/uapi/linux/kvm.h | 7 ++
virt/kvm/vfio.c| 116
-
6 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt
b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..7ecb3b2 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -16,7 +16,22 @@ Groups:
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
+kvm_device_attr.addr points to an int32_t file descriptor
+for the VFIO group.
+
KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
+kvm_device_attr.addr points to an int32_t file descriptor
+for the VFIO group.
+
+ KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: sets a liobn for a VFIO group
+kvm_device_attr.addr points to a struct:
+struct kvm_vfio_spapr_tce_liobn {
+__u32 argsz;
+__u32 fd;
fds are signed, __s32
+__u32 liobn;
+};
+where
+@argsz is a struct size;
+@fd is a file descriptor for a VFIO group;
+@liobn is a logical bus id to be associated with the group.
-For each, kvm_device_attr.addr points to an int32_t file descriptor
-for the VFIO group.
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 61b3535..d1b7f64 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU
+select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+$(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 88ff96a..1d2ad5e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1112,5 +1112,23 @@ static inline bool
kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
}
#endif /* CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT */
+
+typedef void (*kvm_vfio_release_group_callback)(struct kvm *kvm,
+unsigned long liobn);
liobn was said to be __u32 in kvm_vfio_spapr_tce_liobn above, here it's
unsigned long?
PAPR spec says it is 32 bit and kvm_vfio_spapr_tce_liobn is a binary
interface (ABI?) so I want it to be precise.
However kvmppc_get_gpr() (used to parse hypercall parameters such as liobn)
return unsigned long. So inside the kernel I use unsigned long.
So what does make sense to change here?
+
+#if defined(CONFIG_KVM_VFIO) defined(CONFIG_SPAPR_TCE_IOMMU)
+
+extern struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm
Re: [RFC PATCH powerpc] Fix a dma_mask issue of vio
On Thu, 2013-11-21 at 11:22 +1100, Benjamin Herrenschmidt wrote: On Thu, 2013-11-21 at 00:08 +, Russell King - ARM Linux wrote: On Thu, Nov 21, 2013 at 11:01:42AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2013-11-20 at 23:23 +, Russell King - ARM Linux wrote: Li Zong's patch works around the issue of a failing dma_set_mask(), but as I've already said elsewhere, the real fix is to get whatever created the struct device to initialise the dev-dma_mask with a bus default. Using dma_coerce_xxx() merely makes the problem go away papering over the issue - it's fine to do it this way, but someone should still fix the broken code creating these devices... Ok, they are created by the vio bus core, so it should be doing the job here of setting the dma_mask pointer to a proper value. Li, can you take care of that ? Look at other bus types we have in there such as the macio bus etc... Oh, hang on a moment, this is the bus code. In which case, the question becomes: do vio devices ever need to have a separate streaming DMA mask from a coherent DMA mask? If not, then something like the following is what's needed here, and I should've never have used dma_set_mask_and_coherent(). No, a single mask. dma_set_mask_and_coherent() (and the other dma_set_mask() functions) are really supposed to be used by drivers only. arch/powerpc/kernel/vio.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c index e7d0c88f621a..d771778f398e 100644 --- a/arch/powerpc/kernel/vio.c +++ b/arch/powerpc/kernel/vio.c @@ -1419,7 +1419,8 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node) /* needed to ensure proper operation of coherent allocations * later, in case driver doesn't set it explicitly */ - dma_set_mask_and_coherent(viodev-dev, DMA_BIT_MASK(64)); + viodev-dev.coherent_dma_mask = DMA_BIT_MASK(64); + viodev-dev.dma_mask = viodev-dev.coherent_dma_mask; } /* register with generic device framework */ Right that's exactly what I had in mind. Li, can you test this please ? Sure, and it works. Tested-by: Li Zhong zh...@linux.vnet.ibm.com The previous fix using dma_coerce_mask_and_coherent() is already on its way to Linus, so we'll rework the above patch to undo it but for now please test. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: mm: use macro PGTABLE_EADDR_SIZE instead of digital
In case of extending the eaddr in future, use this macro PGTABLE_EADDR_SIZE to ease the maintenance of the code. Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com --- arch/powerpc/mm/slb_low.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/slb_low.S b/arch/powerpc/mm/slb_low.S index 17aa6df..e0b3cf4 100644 --- a/arch/powerpc/mm/slb_low.S +++ b/arch/powerpc/mm/slb_low.S @@ -35,7 +35,7 @@ _GLOBAL(slb_allocate_realmode) * check for bad kernel/user address * (ea ~REGION_MASK) = PGTABLE_RANGE */ - rldicr. r9,r3,4,(63 - 46 - 4) + rldicr. r9,r3,4,(63 - PGTABLE_EADDR_SIZE - 4) bne-8f srdir9,r3,60/* get region */ -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: mm: change pgtable index size for 64K page
For 64K page, we waste half of the pte_t page. With this patch, after changing PGD_INDEX_SIZE from 12 to 11, PTE_INDEX_SIZE from 8 to 9, we can improve the usage of pte_t page and shrink the continuous phys size for pgd_t. Signed-off-by: Liu Ping Fan pingf...@linux.vnet.ibm.com --- arch/powerpc/include/asm/pgtable-ppc64-64k.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/pgtable-ppc64-64k.h b/arch/powerpc/include/asm/pgtable-ppc64-64k.h index a56b82f..f6955ff 100644 --- a/arch/powerpc/include/asm/pgtable-ppc64-64k.h +++ b/arch/powerpc/include/asm/pgtable-ppc64-64k.h @@ -4,10 +4,10 @@ #include asm-generic/pgtable-nopud.h -#define PTE_INDEX_SIZE 8 +#define PTE_INDEX_SIZE 9 #define PMD_INDEX_SIZE 10 #define PUD_INDEX_SIZE 0 -#define PGD_INDEX_SIZE 12 +#define PGD_INDEX_SIZE 11 #ifndef __ASSEMBLY__ #define PTE_TABLE_SIZE (sizeof(real_pte_t) PTE_INDEX_SIZE) -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
linux-next: build failure after merge of the final tree (Linus' tree related - powerpc)
Hi all, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 31: printf: #: invalid number scripts/gcc-version.sh: line 31: printf: #: invalid number stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 31: printf: #: invalid number scripts/gcc-version.sh: line 31: printf: #: invalid number stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian stdin:1:0: error: -mcall-aixdesc must be big endian scripts/gcc-version.sh: line 29: printf: #: invalid number scripts/gcc-version.sh: line 29: printf: #: invalid number scripts/gcc-version.sh: line 29: printf: #: invalid number /bin/sh: line 0: test: 0001 6000 0160: integer expression expected scripts/mod/empty.c:1:0: error: -mcall-aixdesc must be big endian /* empty file to figure out endianness / word size */ ^ scripts/mod/devicetable-offsets.c:1:0: error: -mcall-aixdesc must be big endian #include linux/kbuild.h ^ kernel/bounds.c:1:0: error: -mcall-aixdesc must be big endian /* ^ Caused by commit 7c105b63bd98 (powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option). I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpBlULjp0d08.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: build failure after merge of the final tree (Linus' tree related - powerpc)
Hi, After merging the final tree, today's linux-next build (powerpc allyesconfig) failed like this: stdin:1:0: error: -mcall-aixdesc must be big endian Urgh, allyesconfig is building an LE kernel. Ian: do we need to reverse the polarity of the option, and call it CONFIG_CPU_BIG_ENDIAN? Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix error when cross building TAGS cscope
Currently if I cross build TAGS or cscope from x86 I get this: % make ARCH=powerpc TAGS gcc-4.8.real: error: unrecognized command line option ‘-mbig-endian’ GEN TAGS % I'm not setting CROSS_COMPILE= as logically I shouldn't need to and I haven't needed to in the past when building TAGS or cscope. Also, the above completess correct as the error is not fatal to the build. This was caused by: commit d72b08017161ab385d4ae080ea415c9eb7ceef83 Author: Ian Munsie imun...@au1.ibm.com powerpc: Add ability to build little endian kernels The below fixes this by testing for the -mbig-endian option before adding it. I've not done the same thing in the little endian case as if -mlittle-endian doesn't exist, we probably want to fail quickly as you probably have an old big endian compiler. Signed-off-by: Michael Neuling mi...@neuling.org diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 8a24636..273ace7 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -75,8 +75,10 @@ LDEMULATION := lppc GNUTARGET := powerpcle MULTIPLEWORD := -mno-multiple else +ifeq ($(call cc-option-yn,-mbig-endian),y) override CC+= -mbig-endian override AS+= -mbig-endian +endif override LD+= -EB LDEMULATION:= ppc GNUTARGET := powerpc ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc: Fix missing includes needed for chroma
chroma_defconfig is horribly broken currently, so add a bunch of #includes to fix it. Signed-off-by: Michael Neuling mi...@neuling.org --- So when are we dropping arch/powerpc/platforms/wsp? diff --git a/arch/powerpc/platforms/wsp/chroma.c b/arch/powerpc/platforms/wsp/chroma.c index 8ef53bc..aaa46b3 100644 --- a/arch/powerpc/platforms/wsp/chroma.c +++ b/arch/powerpc/platforms/wsp/chroma.c @@ -15,6 +15,7 @@ #include linux/of.h #include linux/smp.h #include linux/time.h +#include linux/of_fdt.h #include asm/machdep.h #include asm/udbg.h diff --git a/arch/powerpc/platforms/wsp/h8.c b/arch/powerpc/platforms/wsp/h8.c index d18e6cc..a3c87f3 100644 --- a/arch/powerpc/platforms/wsp/h8.c +++ b/arch/powerpc/platforms/wsp/h8.c @@ -10,6 +10,7 @@ #include linux/kernel.h #include linux/of.h #include linux/io.h +#include linux/of_address.h #include wsp.h diff --git a/arch/powerpc/platforms/wsp/ics.c b/arch/powerpc/platforms/wsp/ics.c index 2d3b1dd..3b782ce 100644 --- a/arch/powerpc/platforms/wsp/ics.c +++ b/arch/powerpc/platforms/wsp/ics.c @@ -18,6 +18,8 @@ #include linux/smp.h #include linux/spinlock.h #include linux/types.h +#include linux/of_irq.h +#include linux/of_address.h #include asm/io.h #include asm/irq.h diff --git a/arch/powerpc/platforms/wsp/opb_pic.c b/arch/powerpc/platforms/wsp/opb_pic.c index cb565bf..3f67298 100644 --- a/arch/powerpc/platforms/wsp/opb_pic.c +++ b/arch/powerpc/platforms/wsp/opb_pic.c @@ -15,6 +15,8 @@ #include linux/of.h #include linux/slab.h #include linux/time.h +#include linux/of_address.h +#include linux/of_irq.h #include asm/reg_a2.h #include asm/irq.h diff --git a/arch/powerpc/platforms/wsp/psr2.c b/arch/powerpc/platforms/wsp/psr2.c index 508ec82..a87b414 100644 --- a/arch/powerpc/platforms/wsp/psr2.c +++ b/arch/powerpc/platforms/wsp/psr2.c @@ -15,6 +15,7 @@ #include linux/of.h #include linux/smp.h #include linux/time.h +#include linux/of_fdt.h #include asm/machdep.h #include asm/udbg.h diff --git a/arch/powerpc/platforms/wsp/scom_wsp.c b/arch/powerpc/platforms/wsp/scom_wsp.c index 8928507..6538b4d 100644 --- a/arch/powerpc/platforms/wsp/scom_wsp.c +++ b/arch/powerpc/platforms/wsp/scom_wsp.c @@ -14,6 +14,7 @@ #include linux/of.h #include linux/spinlock.h #include linux/types.h +#include linux/of_address.h #include asm/cputhreads.h #include asm/reg_a2.h diff --git a/arch/powerpc/platforms/wsp/wsp.c b/arch/powerpc/platforms/wsp/wsp.c index ddb6efe..58cd1f0 100644 --- a/arch/powerpc/platforms/wsp/wsp.c +++ b/arch/powerpc/platforms/wsp/wsp.c @@ -13,6 +13,7 @@ #include linux/smp.h #include linux/delay.h #include linux/time.h +#include linux/of_address.h #include asm/scom.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: allyesconfig should not select CONFIG_CPU_LITTLE_ENDIAN
Stephen reported a failure in an allyesconfig build. CONFIG_CPU_LITTLE_ENDIAN=y gets set but his toolchain is not new enough to support little endian. We really want to default to a big endian build; Ben suggested using a choice which defaults to CPU_BIG_ENDIAN. Signed-off-by: Anton Blanchard an...@samba.org --- Index: b/arch/powerpc/platforms/Kconfig.cputype === --- a/arch/powerpc/platforms/Kconfig.cputype +++ b/arch/powerpc/platforms/Kconfig.cputype @@ -404,13 +404,27 @@ config PPC_DOORBELL endmenu -config CPU_LITTLE_ENDIAN - bool Build little endian kernel - default n +choice + prompt Endianness selection + default CPU_BIG_ENDIAN help This option selects whether a big endian or little endian kernel will be built. +config CPU_BIG_ENDIAN + bool Build big endian kernel + help + Build a big endian kernel. + + If unsure, select this option. + +config CPU_LITTLE_ENDIAN + bool Build little endian kernel + help + Build a little endian kernel. + Note that if cross compiling a little endian kernel, CROSS_COMPILE must point to a toolchain capable of targeting little endian powerpc. + +endchoice ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v9] PPC: POWERNV: move iommu_add_device earlier
Hi Alexey,
This patch does 2 things:
1. removes the loop in which PCI devices were added to groups and
adds explicit iommu_add_device() calls to add devices as soon as they get
the iommu_table pointer assigned to them.
2. moves a bus notifier to powernv code in order to avoid conflict with
the notifier from Freescale driver.
This breaks when building with !IOMMU_API for me, as the
iommu_add_device function is declared but not defined. We'd need
something like the following (on top of your change) to work:
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 426d0ec0..04d2abbe 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -102,10 +102,27 @@ extern void iommu_free_table(struct iommu_table *tbl, cons
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#ifdef CONFIG_IOMMU_API
extern void iommu_register_group(struct iommu_table *tbl,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
+#else
+static inline void iommu_register_group(struct iommu_table *tbl,
+int pci_domain_number, unsigned long pe_num)
+{
+}
+
+static inline int iommu_add_device(struct device *dev)
+{
+ return 0;
+}
+
+static inline void iommu_del_device(struct device *dev)
+{
+}
+#endif
static inline void set_iommu_table_base_and_group(struct device *dev,
void *base)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 170b2182..5a02a50f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1212,11 +1212,4 @@ void iommu_del_device(struct device *dev)
}
EXPORT_SYMBOL_GPL(iommu_del_device);
-#else
-
-void iommu_register_group(struct iommu_table *tbl,
- int pci_domain_number, unsigned long pe_num)
-{
-}
-
#endif /* CONFIG_IOMMU_API */
Cheers,
Jeremy
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] iommu: Add empty stub for iommu_group_get_by_id()
Almost every function in include/linux/iommu.h has an empty stub
but the iommu_group_get_by_id() did not get one by mistake.
This adds an empty stub for iommu_group_get_by_id() for IOMMU_API
disabled config.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
include/linux/iommu.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 7ea319e..3c7903d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -245,6 +245,11 @@ static inline struct iommu_domain
*iommu_domain_alloc(struct bus_type *bus)
return NULL;
}
+static inline struct iommu_group *iommu_group_get_by_id(int id)
+{
+ return NULL;
+}
+
static inline void iommu_domain_free(struct iommu_domain *domain)
{
}
--
1.8.4.rc4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v10] PPC: POWERNV: move iommu_add_device earlier
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically the same
thing without using iommu_ops callbacks.
However Freescale PAMU driver (https://lkml.org/lkml/2013/7/1/158)
implements iommu_ops and when tce_iommu_init is called, every PCI device
is already added to some group so there is a conflict.
This patch does 2 things:
1. removes the loop in which PCI devices were added to groups and
adds explicit iommu_add_device() calls to add devices as soon as they get
the iommu_table pointer assigned to them.
2. moves a bus notifier to powernv code in order to avoid conflict with
the notifier from Freescale driver.
iommu_add_device() and iommu_del_device() are public now.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v10:
* fixed linker error when IOMMU_API is not enabled (thanks to Jeremy Kerr)
v9:
* removed KVM from the subject as it is not really a KVM patch so
PPC mainainter (hi Ben!) can review/include it into his tree
v8:
* added the check for iommu_group!=NULL before removing device from a group
as suggested by Wei Yang weiy...@linux.vnet.ibm.com
v2:
* added a helper - set_iommu_table_base_and_group - which does
set_iommu_table_base() and iommu_add_device()
---
arch/powerpc/include/asm/iommu.h| 26
arch/powerpc/kernel/iommu.c | 48 +++--
arch/powerpc/platforms/powernv/pci-ioda.c | 8 ++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 2 +-
arch/powerpc/platforms/powernv/pci.c| 33 +++-
arch/powerpc/platforms/pseries/iommu.c | 8 +++--
6 files changed, 72 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index c34656a..774fa27 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -101,8 +101,34 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+#ifdef CONFIG_IOMMU_API
extern void iommu_register_group(struct iommu_table *tbl,
int pci_domain_number, unsigned long pe_num);
+extern int iommu_add_device(struct device *dev);
+extern void iommu_del_device(struct device *dev);
+#else
+static inline void iommu_register_group(struct iommu_table *tbl,
+ int pci_domain_number,
+ unsigned long pe_num)
+{
+}
+
+static inline int iommu_add_device(struct device *dev)
+{
+ return 0;
+}
+
+static inline void iommu_del_device(struct device *dev)
+{
+}
+#endif /* !CONFIG_IOMMU_API */
+
+static inline void set_iommu_table_base_and_group(struct device *dev,
+ void *base)
+{
+ set_iommu_table_base(dev, base);
+ iommu_add_device(dev);
+}
extern int iommu_map_sg(struct device *dev, struct iommu_table *tbl,
struct scatterlist *sglist, int nelems,
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 572bb5b..d22abe0 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -1105,7 +1105,7 @@ void iommu_release_ownership(struct iommu_table *tbl)
}
EXPORT_SYMBOL_GPL(iommu_release_ownership);
-static int iommu_add_device(struct device *dev)
+int iommu_add_device(struct device *dev)
{
struct iommu_table *tbl;
int ret = 0;
@@ -1134,52 +1134,12 @@ static int iommu_add_device(struct device *dev)
return ret;
}
+EXPORT_SYMBOL_GPL(iommu_add_device);
-static void iommu_del_device(struct device *dev)
+void iommu_del_device(struct device *dev)
{
iommu_group_remove_device(dev);
}
-
-static int iommu_bus_notifier(struct notifier_block *nb,
- unsigned long action, void *data)
-{
- struct device *dev = data;
-
- switch (action) {
- case BUS_NOTIFY_ADD_DEVICE:
- return iommu_add_device(dev);
- case BUS_NOTIFY_DEL_DEVICE:
- iommu_del_device(dev);
- return 0;
- default:
- return 0;
- }
-}
-
-static struct notifier_block tce_iommu_bus_nb = {
- .notifier_call = iommu_bus_notifier,
-};
-
-static int __init tce_iommu_init(void)
-{
- struct pci_dev *pdev = NULL;
-
- BUILD_BUG_ON(PAGE_SIZE IOMMU_PAGE_SIZE);
-
- for_each_pci_dev(pdev)
- iommu_add_device(pdev-dev);
-
- bus_register_notifier(pci_bus_type, tce_iommu_bus_nb);
- return 0;
-}
-
-subsys_initcall_sync(tce_iommu_init);
-
-#else
-
-void iommu_register_group(struct iommu_table *tbl,
- int pci_domain_number, unsigned
