kernel.git/arch/powerpc/include/asm/cputable.h, branch linux-5.16.y

arch: powerpc: Stop building and using oprofile

2021-01-29T04:35:51Z

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:59Z

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

powerpc/32s: Regroup 603 based CPUs in cputable

2020-12-09T05:48:59Z

In order to selectively build the kernel for 603 SW TLB handling, regroup all 603 based CPUs together. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/45065263fdb9f5cc2a2d210ec2a762ac8bf5b2bc.1603348103.git.christophe.leroy@csgroup.eu

powerpc: Retire e200 core (mpc555x processor)

2020-12-05T10:49:18Z

There is no defconfig selecting CONFIG_E200, and no platform. e200 is an earlier version of booke, a predecessor of e500, with some particularities like an unified cache instead of both an instruction cache and a data cache. Remove it. Signed-off-by: Christophe Leroy Acked-by: Scott Wood Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/34ebc3ba2c768d97f363bd5f2deea2356e9ae127.1605589460.git.christophe.leroy@csgroup.eu

powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set

2020-12-03T14:01:34Z

As stated in platform/44x/Kconfig, CONFIG_PPC_47x is not compatible with 440 and 460 variants. This is confirmed in asm/cache.h as L1_CACHE_SHIFT is different for 47x, meaning a kernel built for 47x will not run correctly on a 440. In cputable, opt out all 440 and 460 variants when CONFIG_PPC_47x is set. Also add a default match dedicated to 470. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/822833ce3dc10634339818f7d1ab616edf63b0c6.1603041883.git.christophe.leroy@csgroup.eu

powerpc/feature: Remove CPU_FTR_NODSISRALIGN

2020-12-03T14:01:34Z

CPU_FTR_NODSISRALIGN has not been used since commit 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to handle alignment faults") Remove it. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/05d98136b24bbf11525445414bb18cffe2724f48.1602587470.git.christophe.leroy@csgroup.eu

powerpc/mm: Desintegrate MMU_FTR_PPCAS_ARCH_V2

2020-12-03T14:01:33Z

MMU_FTR_PPCAS_ARCH_V2 is defined in cpu_table.h as MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE. MMU_FTR_TLBIEL and MMU_FTR_16M_PAGE are defined in mmu.h MMU_FTR_PPCAS_ARCH_V2 is used only in mmu.h and it is used only once. Remove MMU_FTR_PPCAS_ARCH_V2 and use directly MMU_FTR_TLBIEL | MMU_FTR_16M_PAGE Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/829ae1aed1d2fc6b5fc5818362e573dee5d6ecde.1602489852.git.christophe.leroy@csgroup.eu

powerpc/feature: Add CPU_FTR_NOEXECUTE to G2_LE

2020-12-03T14:01:33Z

G2_LE has a 603 core, add CPU_FTR_NOEXECUTE. Fixes: 385e89d5b20f ("powerpc/mm: add exec protection on powerpc 603") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/39a530ee41d83f49747ab3af8e39c056450b9b4d.1602489653.git.christophe.leroy@csgroup.eu

powerpc/feature: Use CONFIG_PPC64 instead of powerpc64 to define possible features

2020-12-03T14:01:09Z

In order to build VDSO32 for PPC64, we need to have CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS independant of whether we are building the 32 bits VDSO or the 64 bits VDSO. Use #ifdef CONFIG_PPC64 instead of #ifdef __powerpc64__ Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20201126131006.2431205-1-mpe@ellerman.id.au

powerpc/feature: Fix CPU_FTRS_ALWAYS by removing CPU_FTRS_GENERIC_32

2020-11-19T03:50:16Z

On 8xx, we get the following features: [ 0.000000] cpu_features = 0x0000000000000100 [ 0.000000] possible = 0x0000000000000120 [ 0.000000] always = 0x0000000000000000 This is not correct. As CONFIG_PPC_8xx is mutually exclusive with all other configurations, the three lines should be equal. The problem is due to CPU_FTRS_GENERIC_32 which is taken when CONFIG_BOOK3S_32 is NOT selected. This CPU_FTRS_GENERIC_32 is pointless because there is no generic configuration supporting all 32 bits but book3s/32. Remove this pointless generic features definition to unbreak the calculation of 'possible' features and 'always' features. Fixes: 76bc080ef5a3 ("[POWERPC] Make default cputable entries reflect selected CPU family") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/76a85f30bf981d1aeaae00df99321235494da254.1604426550.git.christophe.leroy@csgroup.eu