kernel/arch/powerpc/include/asm, branch linux-3.2.y

powerpc/pseries: Add empty update_numa_cpu_lookup_table() for NUMA=n

2018-05-31T23:30:16Z

commit c1e150ceb61e4a585bad156da15c33bfe89f5858 upstream. When CONFIG_NUMA is not set, the build fails with: arch/powerpc/platforms/pseries/hotplug-cpu.c:335:4: error: déclaration implicite de la fonction « update_numa_cpu_lookup_table » So we have to add update_numa_cpu_lookup_table() as an empty function when CONFIG_NUMA is not set. Fixes: 1d9a090783be ("powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove") Signed-off-by: Corentin Labbe Signed-off-by: Michael Ellerman Signed-off-by: Ben Hutchings

powerpc/numa: Invalidate numa_cpu_lookup_table on cpu remove

2018-05-31T23:30:13Z

commit 1d9a090783bef19fe8cdec878620d22f05191316 upstream. When DLPAR removing a CPU, the unmapping of the cpu from a node in unmap_cpu_from_node() should also invalidate the CPUs entry in the numa_cpu_lookup_table. There is not a guarantee that on a subsequent DLPAR add of the CPU the associativity will be the same and thus could be in a different node. Invalidating the entry in the numa_cpu_lookup_table causes the associativity to be read from the device tree at the time of the add. The current behavior of not invalidating the CPUs entry in the numa_cpu_lookup_table can result in scenarios where the the topology layout of CPUs in the partition does not match the device tree or the topology reported by the HMC. This bug looks like it was introduced in 2004 in the commit titled "ppc64: cpu hotplug notifier for numa", which is 6b15e4e87e32 in the linux-fullhist tree. Hence tag it for all stable releases. Signed-off-by: Nathan Fontenot Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: - update_numa_cpu_lookup_table() wasn't defined anywhere before - Adjust context] Signed-off-by: Ben Hutchings

powerpc: Correct instruction code for xxlor instruction

2017-11-26T13:51:06Z

commit 93b2d3cf3733b4060d3623161551f51ea1ab5499 upstream. The instruction code for xxlor that commit 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()", 2010-06-15) added is actually the code for xxlnor. It is used in get_vsr() and put_vsr() and the effect of the error is that if emulate_step is used to emulate a VSX load or store from any register other than vsr0, the bitwise complement of the correct value will be loaded or stored. This corrects the error. Fixes: 0016a4cf5582 ("powerpc: Emulate most Book I instructions in emulate_step()") Signed-off-by: Paul Mackerras Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

powerpc/asm: Mark cr0 as clobbered in mftb()

2017-10-12T14:27:16Z

commit 2400fd822f467cb4c886c879d8ad99feac9cf319 upstream. The workaround for the CELL timebase bug does not correctly mark cr0 as being clobbered. This means GCC doesn't know that the asm block changes cr0 and might leave the result of an unrelated comparison in cr0 across the block, which we then trash, leading to basically random behaviour. Fixes: 859deea949c3 ("[POWERPC] Cell timebase bug workaround") Signed-off-by: Oliver O'Halloran [mpe: Tweak change log and flag for stable] Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings

powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash

2017-09-15T17:30:45Z

commit e41e53cd4fe331d0d1f06f8e4ed7e2cc63ee2c34 upstream. virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on an address. What this means in practice is that it should only return true for addresses in the linear mapping which are backed by a valid PFN. We are failing to properly check that the address is in the linear mapping, because virt_to_pfn() will return a valid looking PFN for more or less any address. That bug is actually caused by __pa(), used in virt_to_pfn(). eg: __pa(0xc000000000010000) = 0x10000 # Good __pa(0xd000000000010000) = 0x10000 # Bad! __pa(0x0000000000010000) = 0x10000 # Bad! This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give you something bogus back. Until we can verify if that GCC bug is no longer an issue, or come up with another solution, this commit does the minimal fix to make virt_addr_valid() work, by explicitly checking that the address is in the linear mapping region. Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit") Signed-off-by: Michael Ellerman Reviewed-by: Paul Mackerras Reviewed-by: Balbir Singh Tested-by: Breno Leitao [bwh: Backported to 3.2: open-code virt_to_pfn()] Signed-off-by: Ben Hutchings

net: ethernet: ucc_geth: fix MEM_PART_MURAM mode

2017-08-26T01:14:04Z

commit 8b8642af15ed14b9a7a34d3401afbcc274533e13 upstream. Since commit 5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation"), muram area is not part of immrbar mapping anymore so immrbar_virt_to_phys() is not usable anymore. Fixes: 5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation") Signed-off-by: Christophe Leroy Acked-by: David S. Miller Acked-by: Li Yang Signed-off-by: Scott Wood [bwh: Backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings

powerpc: Ignore reserved field in DCSR and PVR reads and writes

2017-03-16T02:18:45Z

commit 178f358208ceb8b38e5cff3f815e0db4a6a70a07 upstream. IBM bit 31 (for the rest of us - bit 0) is a reserved field in the instruction definition of mtspr and mfspr. Hardware is encouraged to (and does) ignore it. As a result, if userspace executes an mtspr DSCR with the reserved bit set, we get a DSCR facility unavailable exception. The kernel fails to match against the expected value/mask, and we silently return to userspace to try and re-execute the same mtspr DSCR instruction. We loop forever until the process is killed. We should do something here, and it seems mirroring what hardware does is the better option vs killing the process. While here, relax the matching of mfspr PVR too. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: drop changes to PPC_INST_M{F,T}SPR_DSCR_USER_MASK] Signed-off-by: Ben Hutchings

ppc32: fix copy_from_user()

2016-11-20T01:01:39Z

commit 224264657b8b228f949b42346e09ed8c90136a8e upstream. should clear on access_ok() failures. Also remove the useless range truncation logics. Signed-off-by: Al Viro [bwh: Backported to 3.2: no calls to check_object_size()] Signed-off-by: Ben Hutchings

powerpc: scan_features() updates incorrect bits for REAL_LE

2016-06-15T20:28:12Z

commit 6997e57d693b07289694239e52a10d2f02c3a46f upstream. The REAL_LE feature entry in the ibm_pa_feature struct is missing an MMU feature value, meaning all the remaining elements initialise the wrong values. This means instead of checking for byte 5, bit 0, we check for byte 0, bit 0, and then we incorrectly set the CPU feature bit as well as MMU feature bit 1 and CPU user feature bits 0 and 2 (5). Checking byte 0 bit 0 (IBM numbering), means we're looking at the "Memory Management Unit (MMU)" feature - ie. does the CPU have an MMU. In practice that bit is set on all platforms which have the property. This means we set CPU_FTR_REAL_LE always. In practice that seems not to matter because all the modern cpus which have this property also implement REAL_LE, and we've never needed to disable it. We're also incorrectly setting MMU feature bit 1, which is: #define MMU_FTR_TYPE_8xx 0x00000002 Luckily the only place that looks for MMU_FTR_TYPE_8xx is in Book3E code, which can't run on the same cpus as scan_features(). So this also doesn't matter in practice. Finally in the CPU user feature mask, we're setting bits 0 and 2. Bit 2 is not currently used, and bit 0 is: #define PPC_FEATURE_PPC_LE 0x00000001 Which says the CPU supports the old style "PPC Little Endian" mode. Again this should be harmless in practice as no 64-bit CPUs implement that mode. Fix the code by adding the missing initialisation of the MMU feature. Also add a comment marking CPU user feature bit 2 (0x4) as reserved. It would be unsafe to start using it as old kernels incorrectly set it. Fixes: 44ae3ab3358e ("powerpc: Free up some CPU feature bits by moving out MMU-related features") Signed-off-by: Anton Blanchard [mpe: Flesh out changelog, add comment reserving 0x4] Signed-off-by: Michael Ellerman [bwh: Backported to 3.2: adjust filename, context] Signed-off-by: Ben Hutchings

powerpc: Make {cmp}xchg* and their atomic_ versions fully ordered

2016-02-13T10:34:05Z

commit 81d7a3294de7e9828310bbf986a67246b13fa01e upstream. According to memory-barriers.txt, xchg*, cmpxchg* and their atomic_ versions all need to be fully ordered, however they are now just RELEASE+ACQUIRE, which are not fully ordered. So also replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER in __{cmp,}xchg_{u32,u64} respectively to guarantee fully ordered semantics of atomic{,64}_{cmp,}xchg() and {cmp,}xchg(), as a complement of commit b97021f85517 ("powerpc: Fix atomic_xxx_return barrier semantics") This patch depends on patch "powerpc: Make value-returning atomics fully ordered" for PPC_ATOMIC_ENTRY_BARRIER definition. Signed-off-by: Boqun Feng Reviewed-by: Paul E. McKenney Acked-by: Peter Zijlstra (Intel) Signed-off-by: Michael Ellerman [bwh: backported to 3.2: adjust filename] Signed-off-by: Ben Hutchings