kernel.git/arch/powerpc/kernel, branch linux-3.8.y

powerpc: Emulate non privileged DSCR read and write

2013-05-11T20:53:50Z

commit 73d2fb758e678c93bc76d40876c2359f0729b0ef upstream. POWER8 allows read and write of the DSCR in userspace. We added kernel emulation so applications could always use the instructions regardless of the CPU type. Unfortunately there are two SPRs for the DSCR and we only added emulation for the privileged one. Add code to match the non privileged one. A simple test was created to verify the fix: http://ozlabs.org/~anton/junkcode/user_dscr_test.c Without the patch we get a SIGILL and it passes with the patch. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc/power8: Fix secondary CPUs hanging on boot for HV=0

2013-05-08T03:08:16Z

commit 8c2a381734fc9718f127f4aba958e8a7958d4028 upstream. In __restore_cpu_power8 we determine if we are HV and if not, we return before setting HV only resources. Unfortunately we forgot to restore the link register from r11 before returning. This will happen on boot and with secondary CPUs not coming online. This adds the missing link register restore. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Fix hardware IRQs with MMU on exceptions when HV=0

2013-05-08T03:08:16Z

commit 3e96ca7f007ddb06b82a74a68585d1dbafa85ff1 upstream. POWER8 allows us to take interrupts with the MMU on. This gives us a second set of vectors offset at 0x4000. Unfortunately when coping these vectors we missed checking for MSR HV for hardware interrupts (0x500). This results in us trying to use HSRR0/1 when HV=0, rather than SRR0/1 on HW IRQs The below fixes this to check CPU_FTR_HVMODE when patching the code at 0x4500. Also we remove the check for CPU_FTR_ARCH_206 since relocation on IRQs are only available in arch 2.07 and beyond. Thanks to benh for helping find this. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Add isync to copy_and_flush

2013-05-08T03:08:16Z

commit 29ce3c5073057991217916abc25628e906911757 upstream. In __after_prom_start we copy the kernel down to zero in two calls to copy_and_flush. After the first call (copy from 0 to copy_to_here:) we jump to the newly copied code soon after. Unfortunately there's no isync between the copy of this code and the jump to it. Hence it's possible that stale instructions could still be in the icache or pipeline before we branch to it. We've seen this on real machines and it's results in no console output after: calling quiesce... returning from prom_init The below adds an isync to ensure that the copy and flushing has completed before any branching to the new instructions occurs. Signed-off-by: Michael Neuling Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: add a missing label in resume_kernel

2013-04-25T19:51:08Z

commit d8b92292408831d86ff7b781e66bf79301934b99 upstream. A label 0 was missed in the patch a9c4e541 (powerpc/kprobe: Complete kprobe and migrate exception frame). This will cause the kernel branch to an undetermined address if there really has a conflict when updating the thread flags. Signed-off-by: Kevin Hao Acked-By: Tiejun Chen Signed-off-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman

powerpc: Rename USER_ESID_BITS* to ESID_BITS*

2013-03-20T20:10:55Z

commit af81d7878c641629f2693ae3fdaf74b4af14dfca upstream. Now we use ESID_BITS of kernel address to build proto vsid. So rename USER_ESIT_BITS to ESID_BITS Acked-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Update kernel VSID range

2013-03-20T20:10:55Z

commit c60ac5693c47df32a2b4b18af97fca5635def015 upstream. This patch change the kernel VSID range so that we limit VSID_BITS to 37. This enables us to support 64TB with 65 bit VA (37+28). Without this patch we have boot hangs on platforms that only support 65 bit VA. With this patch we now have proto vsid generated as below: We first generate a 37-bit "proto-VSID". Proto-VSIDs are generated from mmu context id and effective segment id of the address. For user processes max context id is limited to ((1ul << 19) - 5) for kernel space, we use the top 4 context ids to map address as below 0x7fffc - [ 0xc000000000000000 - 0xc0003fffffffffff ] 0x7fffd - [ 0xd000000000000000 - 0xd0003fffffffffff ] 0x7fffe - [ 0xe000000000000000 - 0xe0003fffffffffff ] 0x7ffff - [ 0xf000000000000000 - 0xf0003fffffffffff ] Acked-by: Paul Mackerras Signed-off-by: Aneesh Kumar K.V Tested-by: Geoff Levand Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Fix cputable entry for 970MP rev 1.0

2013-03-20T20:10:55Z

commit d63ac5f6cf31c8a83170a9509b350c1489a7262b upstream. Commit 44ae3ab3358e962039c36ad4ae461ae9fb29596c forgot to update the entry for the 970MP rev 1.0 processor when moving some CPU features bits to the MMU feature bit mask. This breaks booting on some rare G5 models using that chip revision. Reported-by: Phileas Fogg Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc: Apply early paca fixups to boot_paca and the boot cpu's paca

2013-03-14T18:26:36Z

commit 25e138149c19fa0680147b825be475f5fd57f155 upstream. In commit 466921c we added a hack to set the paca data_offset to zero so that per-cpu accesses would work on the boot cpu prior to per-cpu areas being setup. This fixed a problem with lockdep touching per-cpu areas very early in boot. However if we combine CONFIG_LOCK_STAT=y with any of the PPC_EARLY_DEBUG options, we can hit the same problem in udbg_early_init(). To avoid that we need to set the data_offset of the boot_paca also. So factor out the fixup logic and call it for both the boot_paca, and "the paca of the boot cpu". Signed-off-by: Michael Ellerman Tested-by: Geoff Levand Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

powerpc/eeh: Fix crash when adding a device in a slot with DDW

2013-02-28T13:38:39Z

commit 6a040ce72598159a74969a2d01ab0ba5ee6536b3 upstream. The DDW code uses a eeh_dev struct from the pci_dev. However, this is not set until eeh_add_device_late is called. Since pci_bus_add_devices is called before eeh_add_device_late, the PCI devices are added to the bus, making drivers' probe hooks to be called. These will call set_dma_mask, which will call the DDW code, which will require the eeh_dev struct from pci_dev. This would result in a crash, due to a NULL dereference. Calling eeh_add_device_late after pci_bus_add_devices would make the system BUG, because device files shouldn't be added to devices there were not added to the system. So, a new function is needed to add such files only after pci_bus_add_devices have been called. Signed-off-by: Thadeu Lima de Souza Cascardo Acked-by: Gavin Shan Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman