kernel/linux.git/arch/powerpc/include/asm/cputable.h, branch v6.7

powerpc/82xx: Remove CONFIG_8260 and CONFIG_8272

2023-08-18T07:03:14+00:00

CONFIG_8272 is never used, remove it. CONFIG_8260 is redundant with CONFIG_PPC_82xx, remove it. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://msgid.link/80930252a5167f3cdaa7eb694074d75521a0bdf9.1692259495.git.christophe.leroy@csgroup.eu

powerpc/dexcr: Add initial Dynamic Execution Control Register (DEXCR) support

2023-06-19T07:36:25+00:00

ISA 3.1B introduces the Dynamic Execution Control Register (DEXCR). It is a per-cpu register that allows control over various CPU behaviours including branch hint usage, indirect branch speculation, and hashst/hashchk support. Add some definitions and basic support for the DEXCR in the kernel. Right now it just * Initialises the DEXCR and HASHKEYR to a fixed value when a CPU onlines. * Clears them in reset_sprs(). * Detects when the NPHIE aspect is supported (the others don't get looked at in this series, so there's no need to waste a CPU_FTR on them). We initialise the HASHKEYR to ensure that all cores have the same key, so an HV enforced NPHIE + swapping cores doesn't randomly crash a process using hash instructions. The stores to HASHKEYR are unconditional because the ISA makes no mention of the SPR being missing if support for doing the hashes isn't present. So all that would happen is the HASHKEYR value gets ignored. This helps slightly if NPHIE detection fails; e.g., we currently only detect it on pseries. Signed-off-by: Benjamin Gray [mpe: Use simple values for DEXCR constants] Signed-off-by: Michael Ellerman Link: https://msgid.link/20230616034846.311705-4-bgray@linux.ibm.com

powerpc: Change CONFIG_E500 to CONFIG_PPC_E500

2022-09-26T13:00:13+00:00

It will be used outside arch/powerpc, make it clear its a powerpc configuration item. And we already have CONFIG_PPC_E500MC, so that will make it more consistent. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/e63b22083c11c4300f4a82d3123a46e5fdd54fa6.1663606876.git.christophe.leroy@csgroup.eu

powerpc: Remove CONFIG_PPC_BOOK3E

2022-09-26T13:00:13+00:00

CONFIG_PPC_BOOK3E is redundant with CONFIG_PPC_BOOK3E_64. The later is more explicit about the fact that it's a 64 bits target. Remove CONFIG_PPC_BOOK3E. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/5d0891490813c19cdcfc04678f512ea68cba3e64.1663606876.git.christophe.leroy@csgroup.eu

powerpc: Remove remaining parts of oprofile

2022-07-27T11:36:05+00:00

Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed oprofile. Remove all remaining parts of it. Signed-off-by: Christophe Leroy Acked-by: Viresh Kumar Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/298432fe1a14c0a415760011d72c3f0999efd5e2.1657204631.git.christophe.leroy@csgroup.eu

powerpc: Enable the DAWR on POWER9 DD2.3 and above

2022-05-22T05:59:53+00:00

The hardware bug in POWER9 preventing use of the DAWR was fixed in DD2.3. Set the CPU_FTR_DAWR feature bit on these newer systems to start using it again, and update the documentation accordingly. The CPU features for DD2.3 are currently determined by "DD2.2 or later" logic. In adding DD2.3 as a discrete case for the first time here, I'm carrying the quirks of DD2.2 forward to keep all behavior outside of this DAWR change the same. This leaves the assessment and potential removal of those quirks on DD2.3 for later. Signed-off-by: Reza Arbab Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220503170152.23412-1-arbab@linux.ibm.com

powerpc/64s: Add CPU_FTRS_POWER10 to ALWAYS mask

2022-05-22T05:59:53+00:00

CPU_FTRS_POWER10 is missing from the CPU_FTRS_ALWAYS mask. Currently that doesn't cause any bug, because it is a superset of the POWER9 mask, which the exception of CPU_FTR_TM, but POWER7 doesn't have CPU_FTR_TM, so CPU_FTR_TM is not in the ALWAYS mask to begin with. However for consistency, and to be robust against future changes, it should be included in the ALWAYS mask. Fixes: a3ea40d5c736 ("powerpc: Add POWER10 architected mode") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220519122205.746276-2-mpe@ellerman.id.au

powerpc/64s: Add CPU_FTRS_POWER9_DD2_2 to CPU_FTRS_ALWAYS mask

2022-05-22T05:59:53+00:00

CPU_FTRS_POWER9_DD2_2 is missing from CPU_FTRS_ALWAYS. That doesn't cause any bug, because CPU_FTRS_POWER9_DD2_2 adds new bits that don't appear in other values, so when anded with the other masks the result is the same. But for consistency we should have all values in the CPU_FTRS_ALWAYS mask, so that the logic is robust against the values being changed in future. Fixes: b5af4f279323 ("powerpc: Add CPU feature bits for TM bug workarounds on POWER9 v2.2") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220519122205.746276-1-mpe@ellerman.id.au

arch: powerpc: Stop building and using oprofile

2021-01-29T04:35:51+00:00

The "oprofile" user-space tools don't use the kernel OPROFILE support any more, and haven't in a long time. User-space has been converted to the perf interfaces. This commits stops building oprofile for powerpc and removes any reference to it from directories in arch/powerpc/ apart from arch/powerpc/oprofile, which will be removed in the next commit (this is broken into two commits as the size of the commit became very big, ~5k lines). Note that the member "oprofile_cpu_type" in "struct cpu_spec" isn't removed as it was also used by other parts of the code. Suggested-by: Christoph Hellwig Suggested-by: Linus Torvalds Signed-off-by: Viresh Kumar Acked-by: Robert Richter Acked-by: William Cohen Acked-by: Al Viro Acked-by: Thomas Gleixner

powerpc/32s: Make support for 603 and 604+ selectable

2020-12-09T05:48:59+00:00

book3s/32 has two main families: - CPU with 603 cores that don't have HASH PTE table and perform SW TLB loading. - Other CPUs based on 604+ cores that have HASH PTE table. This leads to some complex logic and additionnal code to support both. This makes sense for distribution kernels that aim at running on any CPU, but when you are fine tuning a kernel for an embedded 603 based board you don't need all the HASH logic. Allow selection of support for each family, in order to opt out unneeded parts of code. At least one must be selected. Note that some of the CPU supporting HASH also support SW TLB loading, however it is not supported by Linux kernel at the time being, because they do not have alternate registers in the TLB miss exception handlers. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/8dde0cdb629a71abc29b0d85a52a86e920376cb6.1603348103.git.christophe.leroy@csgroup.eu