summaryrefslogtreecommitdiffstats
path: root/arch/powerpc
AgeCommit message (Collapse)AuthorFilesLines
2013-12-20Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds13-62/+112
Pull KVM fixes from Paolo Bonzini: "The PPC folks had a large amount of changes queued for 3.13, and now they are fixing the bugs" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: PPC: Book3S HV: Don't drop low-order page address bits powerpc: book3s: kvm: Don't abuse host r2 in exit path powerpc/kvm/booke: Fix build break due to stack frame size warning KVM: PPC: Book3S: PR: Enable interrupts earlier KVM: PPC: Book3S: PR: Make svcpu -> vcpu store preempt savvy KVM: PPC: Book3S: PR: Export kvmppc_copy_to|from_svcpu KVM: PPC: Book3S: PR: Don't clobber our exit handler id powerpc: kvm: fix rare but potential deadlock scene KVM: PPC: Book3S HV: Take SRCU read lock around kvm_read_guest() call KVM: PPC: Book3S HV: Make tbacct_lock irq-safe KVM: PPC: Book3S HV: Refine barriers in guest entry/exit KVM: PPC: Book3S HV: Fix physical address calculations
2013-12-20Merge tag 'signed-for-3.13' of git://github.com/agraf/linux-2.6 into kvm-masterPaolo Bonzini13-62/+112
Patch queue for 3.13 - 2013-12-18 This fixes some grave issues we've only found after 3.13-rc1: - Make the modularized HV/PR book3s kvm work well as modules - Fix some race conditions - Fix compilation with certain compilers (booke) - Fix THP for book3s_hv - Fix preemption for book3s_pr Alexander Graf (4): KVM: PPC: Book3S: PR: Don't clobber our exit handler id KVM: PPC: Book3S: PR: Export kvmppc_copy_to|from_svcpu KVM: PPC: Book3S: PR: Make svcpu -> vcpu store preempt savvy KVM: PPC: Book3S: PR: Enable interrupts earlier Aneesh Kumar K.V (1): powerpc: book3s: kvm: Don't abuse host r2 in exit path Paul Mackerras (5): KVM: PPC: Book3S HV: Fix physical address calculations KVM: PPC: Book3S HV: Refine barriers in guest entry/exit KVM: PPC: Book3S HV: Make tbacct_lock irq-safe KVM: PPC: Book3S HV: Take SRCU read lock around kvm_read_guest() call KVM: PPC: Book3S HV: Don't drop low-order page address bits Scott Wood (1): powerpc/kvm/booke: Fix build break due to stack frame size warning pingfan liu (1): powerpc: kvm: fix rare but potential deadlock scene
2013-12-18KVM: PPC: Book3S HV: Don't drop low-order page address bitsPaul Mackerras1-0/+1
Commit caaa4c804fae ("KVM: PPC: Book3S HV: Fix physical address calculations") unfortunately resulted in some low-order address bits getting dropped in the case where the guest is creating a 4k HPTE and the host page size is 64k. By getting the low-order bits from hva rather than gpa we miss out on bits 12 - 15 in this case, since hva is at page granularity. This puts the missing bits back in. Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org> Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-18powerpc: book3s: kvm: Don't abuse host r2 in exit pathAneesh Kumar K.V3-4/+5
We don't use PACATOC for PR. Avoid updating HOST_R2 with PR KVM mode when both HV and PR are enabled in the kernel. Without this we get the below crash (qemu) Unable to handle kernel paging request for data at address 0xffffffffffff8310 Faulting instruction address: 0xc00000000001d5a4 cpu 0x2: Vector: 300 (Data Access) at [c0000001dc53aef0] pc: c00000000001d5a4: .vtime_delta.isra.1+0x34/0x1d0 lr: c00000000001d760: .vtime_account_system+0x20/0x60 sp: c0000001dc53b170 msr: 8000000000009032 dar: ffffffffffff8310 dsisr: 40000000 current = 0xc0000001d76c62d0 paca = 0xc00000000fef1100 softe: 0 irq_happened: 0x01 pid = 4472, comm = qemu-system-ppc enter ? for help [c0000001dc53b200] c00000000001d760 .vtime_account_system+0x20/0x60 [c0000001dc53b290] c00000000008d050 .kvmppc_handle_exit_pr+0x60/0xa50 [c0000001dc53b340] c00000000008f51c kvm_start_lightweight+0xb4/0xc4 [c0000001dc53b510] c00000000008cdf0 .kvmppc_vcpu_run_pr+0x150/0x2e0 [c0000001dc53b9e0] c00000000008341c .kvmppc_vcpu_run+0x2c/0x40 [c0000001dc53ba50] c000000000080af4 .kvm_arch_vcpu_ioctl_run+0x54/0x1b0 [c0000001dc53bae0] c00000000007b4c8 .kvm_vcpu_ioctl+0x478/0x730 [c0000001dc53bca0] c0000000002140cc .do_vfs_ioctl+0x4ac/0x770 [c0000001dc53bd80] c0000000002143e8 .SyS_ioctl+0x58/0xb0 [c0000001dc53be30] c000000000009e58 syscall_exit+0x0/0x98 Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-13powerpc/powernv: Fix OPAL LPC access in Little EndianBenjamin Herrenschmidt2-7/+7
We are passing pointers to the firmware for reads, we need to properly convert the result as OPAL is always BE. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc/powernv: Fix endian issue in opal_xscom_readAnton Blanchard2-2/+4
opal_xscom_read uses a pointer to return the data so we need to byteswap it on LE builds. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc: Fix endian issues in crash dump codeAnton Blanchard1-3/+3
A couple more device tree properties that need byte swapping. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc/pseries: Fix endian issues in MSI codeAnton Blanchard1-13/+15
The MSI code is miscalculating quotas in little endian mode. Add required byteswaps to fix this. Before we claimed a quota of 65536, after the patch we see the correct value of 256. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc/pseries: Fix PCIE link speed endian issueAnton Blanchard1-4/+4
We need to byteswap ibm,pcie-link-speed-stats. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc/pseries: Fix endian issues in nvram codeAnton Blanchard1-23/+23
The NVRAM code has a number of endian issues. I noticed a very confused error log count: RTAS: 100663330 -------- RTAS event begin -------- 100663330 == 0x06000022. 0x6 LE error logs and 0x22 BE error logs. The pstore code has similar issues - if we write an oops in one endian and attempt to read it in another we get junk. Make both of these formats big endian, and byteswap as required. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc/pseries: Fix endian issues in /proc/ppc64/lparcfgAnton Blanchard1-6/+6
Some obvious issues: cat /proc/ppc64/lparcfg ... partition_id=16777216 ... partition_potential_processors=268435456 Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc: Fix topology core_id endian issue on LE buildsAnton Blanchard1-2/+2
cpu_to_core_id() is missing a byteswap: cat /sys/devices/system/cpu/cpu63/topology/core_id 201326592 Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc: Fix endian issue in setup-common.cAnton Blanchard1-2/+2
During on LE boot we see: Partition configured for 1073741824 cpus, operating system maximum is 2048. Clearly missing a byteswap here. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-13powerpc: PTRACE_PEEKUSR always returns FPR0Ulrich Weigand1-2/+2
There is a bug in using ptrace to access FPRs via PTRACE_PEEKUSR / PTRACE_POKEUSR. In effect, trying to access any of the FPRs always really accesses FPR0, which does seriously break debugging :-) The problem seems to have been introduced by commit 3ad26e5c4459d (Merge branch 'for-kvm' into next). [ It is indeed a merge conflict between Paul's FPU/VSX state rework and my LE patches - Anton ] Signed-off-by: Ulrich Weigand <Ulrich.Weigand@de.ibm.com> Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-11powerpc/kvm/booke: Fix build break due to stack frame size warningScott Wood3-23/+23
Commit ce11e48b7fdd256ec68b932a89b397a790566031 ("KVM: PPC: E500: Add userspace debug stub support") added "struct thread_struct" to the stack of kvmppc_vcpu_run(). thread_struct is 1152 bytes on my build, compared to 48 bytes for the recently-introduced "struct debug_reg". Use the latter instead. This fixes the following error: cc1: warnings being treated as errors arch/powerpc/kvm/booke.c: In function 'kvmppc_vcpu_run': arch/powerpc/kvm/booke.c:760:1: error: the frame size of 1424 bytes is larger than 1024 bytes make[2]: *** [arch/powerpc/kvm/booke.o] Error 1 make[1]: *** [arch/powerpc/kvm] Error 2 make[1]: *** Waiting for unfinished jobs.... Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-10powerpc: Fix up the kdump base cap to 128MMahesh Salgaonkar1-1/+1
The current logic sets the kdump base to min of 2G or ppc64_rma_size/2. On PowerNV kernel the first memory block 'memory@0' can be very large, equal to the DIMM size with ppc64_rma_size value capped to 1G. Hence on PowerNV, kdump base is set to 512M resulting kdump to fail while allocating paca array. This is because, paca need its memory from RMA region capped at 256M (see allocate_pacas()). This patch lowers the kdump base cap to 128M so that kdump kernel can successfully get memory below 256M for paca allocation. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powernv: Fix VFIO support with PHB3Thadeu Lima de Souza Cascardo1-0/+1
I have recently found out that no iommu_groups could be found under /sys/ on a P8. That prevents PCI passthrough from working. During my investigation, I found out there seems to be a missing iommu_register_group for PHB3. The following patch seems to fix the problem. After applying it, I see iommu_groups under /sys/kernel/iommu_groups/, and can also bind vfio-pci to an adapter, which gives me a device at /dev/vfio/. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powerpc/52xx: Re-enable bestcomm driver in defconfigsAnatolij Gustschin6-6/+12
The bestcomm driver has been moved to drivers/dma, so to select this driver by default additionally CONFIG_DMADEVICES has to be enabled. Currently it is not enabled in the config despite existing CONFIG_PPC_BESTCOMM=y in the config files. Fix it. Signed-off-by: Anatolij Gustschin <agust@denx.de> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powerpc/pasemi: Turn on devtmpfs in defconfigOlof Johansson1-4/+3
At least some distros expect it these days; turn it on. Also, random churn from doing a savedefconfig for the first time in a year or so. Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powerpc: Fix PTE page address mismatch in pgtable ctor/dtorHong H. Pham2-8/+4
In pte_alloc_one(), pgtable_page_ctor() is passed an address that has not been converted by page_address() to the newly allocated PTE page. When the PTE is freed, __pte_free_tlb() calls pgtable_page_dtor() with an address to the PTE page that has been converted by page_address(). The mismatch in the PTE's page address causes pgtable_page_dtor() to access invalid memory, so resources for that PTE (such as the page lock) is not properly cleaned up. On PPC32, only SMP kernels are affected. On PPC64, only SMP kernels with 4K page size are affected. This bug was introduced by commit d614bb041209fd7cb5e4b35e11a7b2f6ee8f62b8 "powerpc: Move the pte free routines from common header". On a preempt-rt kernel, a spinlock is dynamically allocated for each PTE in pgtable_page_ctor(). When the PTE is freed, calling pgtable_page_dtor() with a mismatched page address causes a memory leak, as the pointer to the PTE's spinlock is bogus. On mainline, there isn't any immediately obvious symptoms, but the problem still exists here. Fixes: d614bb041209fd7c "powerpc: Move the pte free routes from common header" Cc: Paul Mackerras <paulus@samba.org> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linux-stable <stable@vger.kernel.org> # v3.10+ Signed-off-by: Hong H. Pham <hong.pham@windriver.com> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powerpc/44x: Fix ocm_block allocationIlia Mirkin1-1/+1
Allocate enough memory for the ocm_block structure, not just a pointer to it. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-10powerpc: Fix build break with PPC_EARLY_DEBUG_BOOTX=yMichael Ellerman1-1/+4
A kernel configured with PPC_EARLY_DEBUG_BOOTX=y but PPC_PMAC=n and PPC_MAPLE=n will fail to link: btext.c:(.text+0x2d0fc): undefined reference to `.rmci_off' btext.c:(.text+0x2d214): undefined reference to `.rmci_on' Fix it by making the build of rmci_on/off() depend on PPC_EARLY_DEBUG_BOOTX, which also enable the only code that uses them. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-09KVM: PPC: Book3S: PR: Enable interrupts earlierAlexander Graf2-10/+2
Now that the svcpu sync is interrupt aware we can enable interrupts earlier in the exit code path again, moving 32bit and 64bit closer together. While at it, document the fact that we're always executing the exit path with interrupts enabled so that the next person doesn't trap over this. Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-09KVM: PPC: Book3S: PR: Make svcpu -> vcpu store preempt savvyAlexander Graf2-0/+23
As soon as we get back to our "highmem" handler in virtual address space we may get preempted. Today the reason we can get preempted is that we replay interrupts and all the lazy logic thinks we have interrupts enabled. However, it's not hard to make the code interruptible and that way we can enable and handle interrupts even earlier. This fixes random guest crashes that happened with CONFIG_PREEMPT=y for me. Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-09KVM: PPC: Book3S: PR: Export kvmppc_copy_to|from_svcpuAlexander Graf1-0/+4
The kvmppc_copy_{to,from}_svcpu functions are publically visible, so we should also export them in a header for others C files to consume. So far we didn't need this because we only called it from asm code. The next patch will introduce a C caller. Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-09KVM: PPC: Book3S: PR: Don't clobber our exit handler idAlexander Graf1-3/+10
We call a C helper to save all svcpu fields into our vcpu. The C ABI states that r12 is considered volatile. However, we keep our exit handler id in r12 currently. So we need to save it away into a non-volatile register instead that definitely does get preserved across the C call. This bug usually didn't hit anyone yet since gcc is smart enough to generate code that doesn't even need r12 which means it stayed identical throughout the call by sheer luck. But we can't rely on that. Signed-off-by: Alexander Graf <agraf@suse.de>
2013-12-07powerpc/512x: dts: remove misplaced IRQ spec from 'soc' nodeGerhard Sittig1-1/+0
the 'soc' node in the common .dtsi for MPC5121 has an '#interrupt-cells' property although this node is not an interrupt controller remove this erroneously placed property because starting with v3.13-rc1 lookup and resolution of 'interrupts' specs for peripherals gets misled, emits 'no irq domain found' WARN() messages and breaks the boot process irq: no irq domain found for /soc@80000000 ! ------------[ cut here ]------------ WARNING: at drivers/of/platform.c:171 Modules linked in: CPU: 0 PID: 1 Comm: swapper Tainted: G W 3.13.0-rc1-00001-g8a66234 #8 task: df823bb0 ti: df834000 task.ti: df834000 NIP: c02b5190 LR: c02b5180 CTR: c01cf4e0 REGS: df835c50 TRAP: 0700 Tainted: G W (3.13.0-rc1-00001-g8a66234) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 229a9d42 XER: 20000000 GPR00: c02b5180 df835d00 df823bb0 00000000 00000000 df835b18 ffffffff 00000308 GPR08: c0479cc0 c0480000 c0479cc0 00000308 00000308 00000000 c00040fc 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 df850880 GPR24: df84d670 00000000 00000001 df8561a0 dffffccc df85089c 00000020 00000001 NIP [c02b5190] of_device_alloc+0xf4/0x1a0 LR [c02b5180] of_device_alloc+0xe4/0x1a0 Call Trace: [df835d00] [c02b5180] of_device_alloc+0xe4/0x1a0 (unreliable) [df835d50] [c02b5278] of_platform_device_create_pdata+0x3c/0xc8 [df835d70] [c02b53fc] of_platform_bus_create+0xf8/0x170 [df835dc0] [c02b5448] of_platform_bus_create+0x144/0x170 [df835e10] [c02b55a8] of_platform_bus_probe+0x98/0xe8 [df835e30] [c0437508] mpc512x_init+0x28/0x1c4 [df835e70] [c0435de8] ppc_init+0x4c/0x60 [df835e80] [c0003b28] do_one_initcall+0x150/0x1a4 [df835ef0] [c0432048] kernel_init_freeable+0x114/0x1c0 [df835f30] [c0004114] kernel_init+0x18/0x124 [df835f40] [c000e910] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 409effd4 57c9103a 57de2834 7c89f050 7f83e378 7c972214 7f45d378 48001f55 7c63d278 7c630034 5463d97e 687a0001 <0f1a0000> 2f990000 387b0010 939b0098 ---[ end trace 2257f10e5a20cbdd ]--- ... irq: no irq domain found for /soc@80000000 ! fsl-diu-fb 80002100.display: could not get DIU IRQ fsl-diu-fb: probe of 80002100.display failed with error -22 irq: no irq domain found for /soc@80000000 ! mpc512x_dma 80014000.dma: Error mapping IRQ! mpc512x_dma: probe of 80014000.dma failed with error -22 ... irq: no irq domain found for /soc@80000000 ! fs_enet: probe of 80002800.ethernet failed with error -22 ... irq: no irq domain found for /soc@80000000 ! mpc5121-rtc 80000a00.rtc: mpc5121_rtc_probe: could not request irq: 0 mpc5121-rtc: probe of 80000a00.rtc failed with error -22 ... Cc: Anatolij Gustschin <agust@denx.de> Cc: linuxppc-dev@lists.ozlabs.org Cc: devicetree@vger.kernel.org Signed-off-by: Gerhard Sittig <gsi@denx.de> Signed-off-by: Anatolij Gustschin <agust@denx.de>
2013-11-25arch/powerpc/kernel: Use %12.12s instead of %12s to avoid memory overflowChen Gang1-1/+1
for tmp_part->header.name: it is "Terminating null required only for names < 12 chars". so need to limit the %.12s for it in printk additional info: %12s limit the width, not for the original string output length if name length is more than 12, it still can be fully displayed. if name length is less than 12, the ' ' will be filled before name. %.12s truly limit the original string output length (precision) Signed-off-by: Chen Gang <gang.chen@asianux.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-25powerpc/signals: Improved mark VSX not saved with small contexts fixMichael Neuling2-9/+13
In a recent patch: commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42 Author: Michael Neuling <mikey@neuling.org> powerpc/signals: Mark VSX not saved with small contexts We fixed an issue but an improved solution was later discussed after the patch was merged. Firstly, this patch doesn't handle the 64bit signals case, which could also hit this issue (but has never been reported). Secondly, the original patch isn't clear what MSR VSX should be set to. The new approach below always clears the MSR VSX bit (to indicate no VSX is in the context) and sets it only in the specific case where VSX is available (ie. when VSX has been used and the signal context passed has space to provide the state). This reverts the original patch and replaces it with the improved solution. It also adds a 64 bit version. Signed-off-by: Michael Neuling <mikey@neuling.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-25powerpc/kdump: Adding symbols in vmcoreinfo to facilitate dump filteringHari Bathini2-0/+13
When CONFIG_SPARSEMEM_VMEMMAP option is used in kernel, makedumpfile fails to filter vmcore dump as it fails to do vmemmap translations. So far dump filtering on ppc64 never had to deal with vmemmap addresses seperately as vmemmap regions where mapped in zone normal. But with the inclusion of CONFIG_SPARSEMEM_VMEMMAP config option in kernel, this vmemmap address translation support becomes necessary for dump filtering. For vmemmap adress translation, few kernel symbols are needed by dump filtering tool. This patch adds those symbols to vmcoreinfo, which a dump filtering tool can use for filtering the kernel dump. Tested this changes successfully with makedumpfile tool that supports vmemmap to physical address translation outside zone normal. [ Removed unneeded #ifdef as suggested by Michael Ellerman --BenH ] Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-25powerpc: allyesconfig should not select CONFIG_CPU_LITTLE_ENDIANAnton Blanchard1-3/+17
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 <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-25powerpc: Fix error when cross building TAGS & cscopeMichael Neuling1-0/+2
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 <imunsie@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 <mikey@neuling.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-22powerpc/booke: Only check for hugetlb in flush if vma != NULLScott Wood2-3/+2
And in flush_hugetlb_page(), don't check whether vma is NULL after we've already dereferenced it. This was found by Dan using static analysis as described here: https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-November/113161.html We currently get away with this because the callers that currently pass NULL for vma seem to be 32-bit-only (e.g. highmem, and CONFIG_DEBUG_PGALLOC in pgtable_32.c) Hugetlb is currently 64-bit only, so we never saw a NULL vma here. Signed-off-by: Scott Wood <scottwood@freescale.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
2013-11-22powerpc/85xx: typo in dts: "interupt" (four devices)Adam Borowski4-8/+8
These lines were inoperative for four years, which puts some doubt into their importance, and it's possible the fixed version will regress, but at the very least they should be removed instead. Signed-off-by: Adam Borowski <kilobyte@angband.pl> Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-11-22powerpc/8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supportedLEROY Christophe5-0/+37
Commit beb2dc0a7a84be003ce54e98b95d65cc66e6e536 breaks the MPC8xx which seems to not support using mfspr SPRN_TBRx instead of mftb/mftbu despite what is written in the reference manual. This patch reverts to the use of mftb/mftbu when CONFIG_8xx is selected. Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-11-22powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU wellTiejun Chen1-0/+5
If CONFIG_ALTIVEC is enabled for CoreNet64, and if we also select CONFIG_E{5,6}500_CPU this may introduce -mcpu=e500mc64 into $CFLAGS. But Altivec option not allowed with e500mc64, then some compiling errors occur like this: 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 So we should restrict e500mc64 in altivec scenario. Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com> Signed-off-by: Scott Wood <scottwood@freescale.com>
2013-11-22Merge branch 'merge' of ↵Linus Torvalds20-36/+75
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull third set of powerpc updates from Benjamin Herrenschmidt: "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" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/signals: Mark VSX not saved with small contexts powerpc/pseries: Fix SMP=n build of rng.c powerpc: Make cpu_to_chip_id() available when SMP=n powerpc/vio: Fix a dma_mask issue of vio powerpc: booke: Fix build failures powerpc: ppc64 address space capped at 32TB, mmap randomisation disabled powerpc: Only print PACATMSCRATCH in oops when TM is active powerpc/pseries: Duplicate dtl entries sometimes sent to userspace powerpc: Remove a few lines of oops output powerpc: Print DAR and DSISR on machine check oopses powerpc: Fix __get_user_pages_fast() irq handling powerpc/eeh: More accurate log powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridges
2013-11-21powerpc/signals: Mark VSX not saved with small contextsMichael Neuling1-1/+9
The VSX MSR bit in the user context indicates if the context contains VSX state. Currently we set this when the process has touched VSX at any stage. Unfortunately, if the user has not provided enough space to save the VSX state, we can't save it but we currently still set the MSR VSX bit. This patch changes this to clear the MSR VSX bit when the user doesn't provide enough space. This indicates that there is no valid VSX state in the user context. This is needed to support get/set/make/swapcontext for applications that use VSX but only provide a small context. For example, getcontext in glibc provides a smaller context since the VSX registers don't need to be saved over the glibc function call. But since the program calling getcontext may have used VSX, the kernel currently says the VSX state is valid when it's not. If the returned context is then used in setcontext (ie. a small context without VSX but with MSR VSX set), the kernel will refuse the context. This situation has been reported by the glibc community. Based on patch from Carlos O'Donell. Tested-by: Haren Myneni <haren@linux.vnet.ibm.com> Signed-off-by: Michael Neuling <mikey@neuling.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/pseries: Fix SMP=n build of rng.cMichael Ellerman1-0/+1
In commit a489043 "Implement arch_get_random_long() based on H_RANDOM" I broke the SMP=n build. We were getting plpar_wrappers.h via spinlock.h which breaks when SMP=n. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Make cpu_to_chip_id() available when SMP=nMichael Ellerman4-17/+22
Up until now we have only used cpu_to_chip_id() in the topology code, which is only used on SMP builds. However my recent commit a4da0d5 "Implement arch_get_random_long/int() for powernv" added a usage when SMP=n, breaking the build. Move cpu_to_chip_id() into prom.c so it is available for SMP=n builds. We would move the extern to prom.h, but that breaks the include in topology.h. Instead we leave it in smp.h, but move it out of the CONFIG_SMP #ifdef. We also need to include asm/smp.h in rng.c, because the linux version skips asm/smp.h on UP. What a mess. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/vio: Fix a dma_mask issue of vioLi Zhong1-1/+1
I encountered following issue: [ 0.283035] ibmvscsi 30000015: couldn't initialize event pool [ 5.688822] ibmvscsi: probe of 30000015 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. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: booke: Fix build failuresAneesh Kumar K.V7-0/+9
arch/powerpc/platforms/wsp/wsp.c: In function ‘wsp_probe_devices’: arch/powerpc/platforms/wsp/wsp.c:76:3: error: implicit declaration of function ‘of_address_to_resource’ [-Werror=implicit-function-declaration] Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: ppc64 address space capped at 32TB, mmap randomisation disabledAnton Blanchard1-1/+1
Commit fba2369e6ceb (mm: use vm_unmapped_area() on powerpc architecture) has a bug in slice_scan_available() where we compare an unsigned long (high_slices) against a shifted int. As a result, comparisons against the top 32 bits of high_slices (representing the top 32TB) always returns 0 and the top of our mmap region is clamped at 32TB This also breaks mmap randomisation since the randomised address is always up near the top of the address space and it gets clamped down to 32TB. Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Michel Lespinasse <walken@google.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Only print PACATMSCRATCH in oops when TM is activeAnton Blanchard1-1/+2
If TM is not active there is no need to print PACATMSCRATCH so we can save ourselves a line. Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Michael Neuling <mikey@neuling.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/pseries: Duplicate dtl entries sometimes sent to userspaceAnton Blanchard1-2/+2
When reading from the dispatch trace log (dtl) userspace interface, I sometimes see duplicate entries. One example: # hexdump -C dtl.out 00000000 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000010 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000020 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 00000030 07 04 00 0c 00 00 48 44 00 00 00 00 00 00 00 00 00000040 00 0c a0 b4 16 83 6d 68 00 00 00 00 00 00 00 00 00000050 00 00 00 00 10 00 13 50 80 00 00 00 00 00 d0 32 The problem is in scan_dispatch_log() where we call dtl_consumer() but bail out before incrementing the index. To fix this I moved dtl_consumer() after the timebase comparison. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: stable@vger.kernel.org Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Remove a few lines of oops outputAnton Blanchard1-9/+9
We waste quite a few lines in our oops output: ... MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 SOFTE: 0 CFAR: 0000000000009088 DAR: 000000000000001c, DSISR: 40000000 GPR00: c0000000000c74f0 c00000037cc1b010 c000000000d2bb30 0000000000000000 ... We can do a better job here and remove 3 lines: MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 28044024 XER: 00000000 CFAR: 0000000000009088 DAR: 0000000000000010, DSISR: 40000000 SOFTE: 1 GPR00: c0000000000e3d10 c00000037cc2fda0 c000000000d2c3a8 0000000000000001 Also move PACATMSCRATCH up, it doesn't really belong in the stack trace section. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Print DAR and DSISR on machine check oopsesAnton Blanchard1-1/+1
Machine check exceptions set DAR and DSISR, so print them in our oops output. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc: Fix __get_user_pages_fast() irq handlingHeiko Carstens1-2/+3
__get_user_pages_fast() may be called with interrupts disabled (see e.g. get_futex_key() in kernel/futex.c) and therefore should use local_irq_save() and local_irq_restore() instead of local_irq_disable()/enable(). Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> CC: <stable@vger.kernel.org> [v3.12] Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/eeh: More accurate logGavin Shan1-2/+7
This clarifies in the log whether the error is a global PHB error or an individual PE being frozen. Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-11-21powerpc/eeh: Enable PCI_COMMAND_MASTER for PCI bridgesGavin Shan1-0/+9
On PHB3, we will fail to fetch IODA tables without PCI_COMMAND_MASTER on PCI bridges. According to one experiment I had, the MSIx interrupts didn't raise from the adapter without the bit applied to all upstream PCI bridges including root port of the adapter. The patch forces to have that bit enabled accordingly. Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com> CC: <stable@vger.kernel.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 19:33:38 +0000