aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28powerpc/signal: Update comment for clarityRashmica Gupta1-3/+6
The comment being referred to was deleted in commit af1bbc3dd3d5 ("powerpc: Remove UP only lazy floating point and vector optimisations"). Add a bit more detail so it's clear why we need to clear the FP/VEC/VSX bits here. Signed-off-by: Rashmica Gupta <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc: make facility_unavailable_exception 64sRashmica Gupta1-1/+1
The facility unavailable exception is only available on ppc book3s machines so use CONFIG_PPC_BOOK3S_64 rather than CONFIG_PPC64. tm_unavailable is only called from facility_unavailable_exception so can also be under this Kconfig symbol. Signed-off-by: Rashmica Gupta <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/platforms/83xx/suspend: Remove write-only global variableUwe Kleine-König1-2/+0
pmc_dev is only assigned in .probe(), otherwise the variable is unused. So drop this pointer that serves no purpose. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/platforms/83xx/suspend: Prevent unloading the driverUwe Kleine-König1-6/+1
Returning an error in .remove() doesn't prevent a driver from being unloaded. On unbind this only results in an error message, but the device is remove anyhow. I guess the author's idea of just returning -EPERM in .remove() was to prevent unbinding a device. To achieve that set the suppress_bind_attrs driver property and drop the useless .remove callback. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Acked-by: Scott Wood <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/platforms/83xx/suspend: Reorder to get rid of a forward declarationUwe Kleine-König1-22/+21
By moving up pmc_types and pmc_match, the forward declaration for pmc_match can be dropped. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/sysdev: Fix comment typoJason Wang1-1/+1
The double `is' is duplicated in line 110, remove one. Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/pseries/vas: Fix comment typoJason Wang1-1/+1
The double `the' in line 807 is duplicated, remove one. Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/85xx: P2020: Add law_trgt_if property to PCIe DT nodesPali Rohár1-0/+3
DT law_trgt_if property defines Local Access Window Target Interface. Local Access Window Target Interface is used for identifying individual peripheral and mapping its memory to CPU. Interface id is defined by hardware itself. U-Boot uses law_trgt_if DT property in PCIe nodes for configuring memory mapping of individual PCIe controllers. Linux kernel fsl_pci.c driver currently does not touch Local Access Window and expects that U-Boot configures it properly. Add law_trgt_if property to PCIe DT nodes for P2020. This allows usage of kernel P2020 PCIe DT nodes in U-Boot. And therefore allows to share P2020 DTS files between Linux kernel and U-Boot. Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and aliasPali Rohár1-8/+19
Other Linux architectures use DT property 'linux,pci-domain' for specifying fixed PCI domain of PCI controller specified in Device-Tree. And lot of Freescale powerpc boards have defined numbered pci alias in Device-Tree for every PCIe controller which number specify preferred PCI domain. So prefer usage of DT property 'linux,pci-domain' (via function of_get_pci_domain_nr()) and DT pci alias (via function of_alias_get_id()) on powerpc architecture for assigning PCI domain to PCI controller. Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/85xx: Fix description of MPC85xx and P1/P2 boards optionsPali Rohár1-8/+10
More MPC85xx and P1/P2 boards options have incorrect description. Fix them to include list of all boards for which they enable/disable support. Signed-off-by: Pali Rohár <[email protected]> Acked-by: Scott Wood <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/pseries: define driver for Platform KeyStoreNayna Jain5-0/+556
PowerVM provides an isolated Platform Keystore(PKS) storage allocation for each LPAR with individually managed access controls to store sensitive information securely. It provides a new set of hypervisor calls for Linux kernel to access PKS storage. Define POWER LPAR Platform KeyStore(PLPKS) driver using H_CALL interface to access PKS storage. Signed-off-by: Nayna Jain <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/iommu: Fix iommu_table_in_use for a small default DMA window caseAlexey Kardashevskiy1-0/+5
The existing iommu_table_in_use() helper checks if the kernel is using any of TCEs. There are some reserved TCEs: 1) the very first one if DMA window starts from 0 to avoid having a zero but still valid DMA handle; 2) it_reserved_start..it_reserved_end to exclude MMIO32 window in case the default window spans across that - this is the default for the first DMA window on PowerNV. When 1) is the case and 2) is not the helper does not skip 1) and returns wrong status. This only seems occurring when passing through a PCI device to a nested guest (not something we support really well) so it has not been seen before. This fixes the bug by adding a special case for no MMIO32 reservation. Fixes: 3c33066a2190 ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/ioda/iommu/debugfs: Generate unique debugfs entriesAlexey Kardashevskiy1-0/+2
The iommu_table::it_index is a LIOBN which is not initialized on PowerNV as it is not used except IOMMU debugfs where it is used for a node name. This initializes it_index witn a unique number to avoid warnings and have a node for every iommu_table. This should not cause any behavioral change without CONFIG_IOMMU_DEBUGFS. Signed-off-by: Alexey Kardashevskiy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-windowAlexey Kardashevskiy2-41/+102
The pseries platform uses 32bit default DMA window (always 4K pages) and optional 64bit DMA window available via DDW ("Dynamic DMA Windows"), 64K or 2M pages. For ages the default one was not removed and a huge window was created in addition. Things changed with SRIOV-enabled PowerVM which creates a default-and-bigger DMA window in 64bit space (still using 4K pages) for IOV VFs so certain OSes do not need to use the DDW API in order to utilize all available TCE budget. Linux on the other hand removes the default window and creates a bigger one (with more TCEs or/and a bigger page size - 64K/2M) in a bid to map the entire RAM, and if the new window size is smaller than that - it still uses this new bigger window. The result is that the default window is removed but the "ibm,dma-window" property is not. When kdump is invoked, the existing code tries reusing the existing 64bit DMA window which location and parameters are stored in the device tree but this fails as the new property does not make it to the kdump device tree blob. So the code falls back to the default window which does not exist anymore although the device tree says that it does. The result of that is that PCI devices become unusable and cannot be used for kdumping. This preserves the DMA64 and DIRECT64 properties in the device tree blob for the crash kernel. Since the crash kernel setup is done after device drivers are loaded and probed, the proper DMA config is stored at least for boot time devices. Because DDW window is optional and the code configures the default window first, the existing code creates an IOMMU table descriptor for the non-existing default DMA window. It is harmless for kdump as it does not touch the actual window (only reads what is mapped and marks those IO pages as used) but it is bad for kexec which clears it thinking it is a smaller default window rather than a bigger DDW window. This removes the "ibm,dma-window" property from the device tree after a bigger window is created and the crash kernel setup picks it up. Fixes: 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by: Alexey Kardashevskiy <[email protected]> Acked-by: Hari Bathini <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc/crash: save cpu register data in crash_smp_send_stop()Hari Bathini3-50/+57
During kdump, two set of NMI IPIs are sent to secondary CPUs, if 'crash_kexec_post_notifiers' option is set. The first set of NMI IPIs to stop the CPUs and the other set to collect register data. Instead, capture register data for secondary CPUs while stopping them itself. Also, fallback to smp_send_stop() in case the function gets called without kdump configured. Signed-off-by: Hari Bathini <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc: Update reviewersMichael Ellerman1-2/+2
Christophe and Nick have been active in recent years on the mailing list and making contributions, add them as reviewers. Paul and Ben are no longer actively reviewing powerpc patches, remove them from the reviewers, they're still on linuxppc-dev if needed. Acked-by: Benjamin Herrenschmidt <[email protected]> Acked-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-28powerpc: Finally remove unnecessary headers from asm/prom.hChristophe Leroy1-8/+2
Remove all headers included from asm/prom.h which are not used by asm/prom.h itself. Declare struct device_node and struct property locally to avoid including of.h Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/4be954abef978b34cff9193fc566ffefdd3517bb.1657264228.git.christophe.leroy@csgroup.eu
2022-07-28powerpc: Remove asm/prom.h from asm/mpc52xx.h and asm/pci.hChristophe Leroy4-2/+5
asm/pci.h and asm/mpc52xx.h don't need asm/prom.h Declare struct device_node locally to avoid including of.h Signed-off-by: Christophe Leroy <[email protected]> [mpe: Add missing include of prom.h to of_rtc.c] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/cf5243343e2364c2b40f22ee5ad9a6e2453d1121.1657264228.git.christophe.leroy@csgroup.eu
2022-07-28EDAC/mpc85xx: Include required of headers directlyMichael Ellerman1-0/+2
A subsequent commit to cleanup powerpc's asm/prom.h leads to build errors in mpc85xx_edac.c due to missing headers. Include all required headers directly to avoid the build failure. Reported-by: kernel test robot <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2022-07-28scsi: cxlflash: Include missing linux/irqdomain.hChristophe Leroy1-0/+1
powerpc's asm/prom.h brings some headers that it doesn't need itself. Once those headers are removed from asm/prom.h, the following errors occur: CC [M] drivers/scsi/cxlflash/ocxl_hw.o drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_map_irq': drivers/scsi/cxlflash/ocxl_hw.c:195:16: error: implicit declaration of function 'irq_create_mapping' [-Werror=implicit-function-declaration] 195 | virq = irq_create_mapping(NULL, irq->hwirq); | ^~~~~~~~~~~~~~~~~~ drivers/scsi/cxlflash/ocxl_hw.c:222:9: error: implicit declaration of function 'irq_dispose_mapping' [-Werror=implicit-function-declaration] 222 | irq_dispose_mapping(virq); | ^~~~~~~~~~~~~~~~~~~ drivers/scsi/cxlflash/ocxl_hw.c: In function 'afu_unmap_irq': drivers/scsi/cxlflash/ocxl_hw.c:264:13: error: implicit declaration of function 'irq_find_mapping'; did you mean 'is_cow_mapping'? [-Werror=implicit-function-declaration] 264 | if (irq_find_mapping(NULL, irq->hwirq)) { | ^~~~~~~~~~~~~~~~ | is_cow_mapping cc1: some warnings being treated as errors Fix it by including linux/irqdomain.h Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/c6c0cc5e9179a642370a61439f95158271a78c03.1657264228.git.christophe.leroy@csgroup.eu
2022-07-28video: fbdev: offb: Include missing linux/platform_device.hChristophe Leroy1-0/+1
A lot of drivers were getting platform and of headers indirectly via headers like asm/pci.h or asm/prom.h Most of them were fixed during 5.19 cycle but a newissue was introduced by commit 52b1b46c39ae ("of: Create platform devices for OF framebuffers") Include missing platform_device.h to allow cleaning asm/pci.h Fixes: 52b1b46c39ae ("of: Create platform devices for OF framebuffers") Signed-off-by: Christophe Leroy <[email protected]> Acked-by: Helge Deller <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/f75b383673663e27f6b57e50b4abfb9fe3780b00.1657264228.git.christophe.leroy@csgroup.eu
2022-07-28docs: powerpc: add elf_hwcaps to table of contentsBagas Sanjaya1-0/+1
elf_hwcaps documentation is missing from table of contents at index.rst, hence triggers Sphinx warning: Documentation/powerpc/elf_hwcaps.rst: WARNING: document isn't included in any toctree Add the documentation to the index to fix the warning. Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/linuxppc-dev/[email protected]/ Link: https://lore.kernel.org/r/[email protected]
2022-07-28docs: powerpc: use different label name for elf_hwcaps.rstBagas Sanjaya1-1/+1
Sphinx reported duplicate label warning: WARNING: duplicate label elf_hwcaps_index, other instance in Documentation/arm64/elf_hwcaps.rst The warning is caused by elf_hwcaps_index label name is already used for arm64 documentation, whileas powerpc use the same name. Disambiguate the label name for powerpc. Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/linuxppc-dev/[email protected]/ Link: https://lore.kernel.org/r/[email protected]
2022-07-28docs: powerpc: fix indentation warningsBagas Sanjaya1-9/+6
Sphinx reported unexpected indentation warnings: Documentation/powerpc/elf_hwcaps.rst:82: WARNING: Unexpected indentation. Documentation/powerpc/elf_hwcaps.rst:100: WARNING: Unexpected indentation. Documentation/powerpc/elf_hwcaps.rst:117: WARNING: Unexpected indentation. Documentation/powerpc/elf_hwcaps.rst:122: WARNING: Unexpected indentation. Documentation/powerpc/elf_hwcaps.rst:144: WARNING: Unexpected indentation. Fix these warnings by unindenting commit references and using literal code block for instructions list for PPC_FEATURE_ICACHE_SNOOP. Fixes: 3df1ff42e69e91 ("powerpc: add documentation for HWCAPs") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Bagas Sanjaya <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/linuxppc-dev/[email protected]/ Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/64e: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')Christophe Leroy2-11/+5
With GCC 12, corenet64_smp_defconfig leads to the following build errors: CC arch/powerpc/kernel/irq.o {standard input}: Assembler messages: {standard input}:3616: Error: unrecognized opcode: `wrteei' {standard input}:5689: Error: unrecognized opcode: `wrteei' CC arch/powerpc/kernel/pmc.o {standard input}: Assembler messages: {standard input}:42: Error: unrecognized opcode: `mfpmr' {standard input}:53: Error: unrecognized opcode: `mtpmr' CC arch/powerpc/kernel/io.o {standard input}: Assembler messages: {standard input}:376: Error: unrecognized opcode: `mbar' ... CC arch/powerpc/mm/nohash/book3e_hugetlbpage.o {standard input}: Assembler messages: {standard input}:291: Error: unrecognized opcode: `tlbsx' {standard input}:482: Error: unrecognized opcode: `tlbwe' {standard input}:608: Error: unrecognized opcode: `lbarx' {standard input}:608: Error: unrecognized opcode: `stbcx.' -mpcu=powerpc64 cannot be used anymore for book3e, it must be a booke CPU. But then we get: CC arch/powerpc/lib/xor_vmx.o cc1: error: AltiVec not supported in this target Altivec is not supported with -mcpu=e5500 so don't allow selection of altivec when e5500 is selected. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/77255a5a957967723b84d0356d9e5fb21569f4e8.1657549153.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/44x: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')Christophe Leroy6-7/+35
Building ppc40x_defconfig leads to following error CC arch/powerpc/kernel/idle.o {standard input}: Assembler messages: {standard input}:67: Error: unrecognized opcode: `wrteei' {standard input}:78: Error: unrecognized opcode: `wrteei' Add -mcpu=440 by default and alternatively 464 and 476. Once that's done, -mcpu=powerpc is only for book3s/32 now. But then comes CC arch/powerpc/kernel/io.o {standard input}: Assembler messages: {standard input}:198: Error: unrecognized opcode: `eieio' {standard input}:230: Error: unrecognized opcode: `eieio' {standard input}:245: Error: unrecognized opcode: `eieio' {standard input}:254: Error: unrecognized opcode: `eieio' {standard input}:273: Error: unrecognized opcode: `eieio' {standard input}:396: Error: unrecognized opcode: `eieio' {standard input}:404: Error: unrecognized opcode: `eieio' {standard input}:423: Error: unrecognized opcode: `eieio' {standard input}:512: Error: unrecognized opcode: `eieio' {standard input}:520: Error: unrecognized opcode: `eieio' {standard input}:539: Error: unrecognized opcode: `eieio' {standard input}:628: Error: unrecognized opcode: `eieio' {standard input}:636: Error: unrecognized opcode: `eieio' {standard input}:655: Error: unrecognized opcode: `eieio' Fix it by replacing eieio by mbar on booke. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/b0d982e223314ed82ab959f5d4ad2c4c00bedb99.1657549153.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/405: Fix build failure with GCC 12 (unrecognized opcode: `wrteei')Christophe Leroy1-1/+6
Building ppc40x_defconfig leads to following error CC arch/powerpc/kernel/process.o {standard input}: Assembler messages: {standard input}:626: Error: unrecognized opcode: `wrteei' Add -mcpu=405 by default. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/d344a42c99061cfe10a28e00de4e31a1363f4251.1657549153.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/32: Don't always pass -mcpu=powerpc to the compilerChristophe Leroy2-28/+19
Since commit 4bf4f42a2feb ("powerpc/kbuild: Set default generic machine type for 32-bit compile"), when building a 32 bits kernel with a bi-arch version of GCC, or when building a book3s/32 kernel, the option -mcpu=powerpc is passed to GCC at all time, relying on it being eventually overriden by a subsequent -mcpu=xxxx. But when building the same kernel with a 32 bits only version of GCC, that is not done, relying on gcc being built with the expected default CPU. This logic has two problems. First, it is a bit fragile to rely on whether the GCC version is bi-arch or not, because today we can have bi-arch versions of GCC configured with a 32 bits default. Second, there are some versions of GCC which don't support -mcpu=powerpc, for instance for e500 SPE-only versions. So, stop relying on this approximative logic and allow the user to decide whether he/she wants to use the toolchain's default CPU or if he/she wants to set one, and allow only possible CPUs based on the selected target. Reported-by: Pali Rohár <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Tested-by: Pali Rohár <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/32: Do not allow selection of e5500 or e6500 CPUs on PPC32Christophe Leroy1-2/+2
Commit 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") enlarged the CPU selection logic to PPC32 by removing depend to PPC64, and failed to restrict that depend to E5500_CPU and E6500_CPU. Fortunately that got unnoticed because -mcpu=8540 will override the -mcpu=e500mc64 or -mpcu=e6500 as they are ealier, but that's fragile and may no be right in the future. Add back the depend PPC64 on E5500_CPU and E6500_CPU. Fixes: 0e00a8c9fd92 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/8abab4888da69ff78b73a56f64d9678a7bf684e9.1657549153.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/ppc-opcode: Define and use PPC_RAW_SETB()Christophe Leroy2-7/+4
We have PPC_INST_SETB then build the 'setb' instruction in the user. Instead, define PPC_RAW_SETB() and use it. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/b08a4f26919a8f8cdcf7544ab552d9c1c63418b5.1657205708.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/ppc-opcode: Define and use PPC_RAW_TRAP() and PPC_RAW_TW()Christophe Leroy3-2/+5
Add and use PPC_RAW_TRAP() instead of opencoding. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/52c7e522e56a38e3ff0363906919445920005a8f.1657205708.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/probes: Remove ppc_opcode_tChristophe Leroy3-3/+2
ppc_opcode_t is just an u32. There is no point in hiding u32 behind such a typedef. Remove it. Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/b2d762191b095530789ac8b71b167c6740bb6aed.1657205708.git.christophe.leroy@csgroup.eu
2022-07-27powerpc: Remove remaining parts of oprofileChristophe Leroy5-74/+4
Commit 9850b6c69356 ("arch: powerpc: Remove oprofile") removed oprofile. Remove all remaining parts of it. Signed-off-by: Christophe Leroy <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/298432fe1a14c0a415760011d72c3f0999efd5e2.1657204631.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/perf: Use PVR rather than oprofile field to determine CPU versionRashmica Gupta12-33/+37
Currently the perf CPU backend drivers detect what CPU they're on using cur_cpu_spec->oprofile_cpu_type. Although that works, it's a bit crufty to be using oprofile related fields, especially seeing as oprofile is more or less unused these days. It also means perf is reliant on the fragile logic in setup_cpu_spec() which detects when we're using a logical PVR and copies back the PMU related fields from the raw CPU entry. So lets check the PVR directly. Suggested-by: Michael Ellerman <[email protected]> Signed-off-by: Rashmica Gupta <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Reviewed-by: Madhavan Srinivasan <[email protected]> [chleroy: Added power10 and fixed checkpatch issues] Reviewed-and-tested-by: Athira Rajeev <[email protected]> Reviewed-and-tested-By: Kajol Jain <[email protected]> [For 24x7 side changes] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/20c0ee7f99dbf0dbf8658df6b39f84753e6db1ef.1657204631.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/32s: Fix boot failure with KASAN + SMP + JUMP_LABEL_FEATURE_CHECK_DEBUGChristophe Leroy1-1/+1
Since commit 4291d085b0b0 ("powerpc/32s: Make pte_update() non atomic on 603 core"), pte_update() has been using mmu_has_feature(MMU_FTR_HPTE_TABLE) to avoid a useless atomic operation on 603 cores. When kasan_early_init() sets up the early zero shadow, it uses __set_pte_at(). On book3s/32, __set_pte_at() calls pte_update() when CONFIG_SMP is selected in order to ensure the preservation of _PAGE_HASHPTE in case of concurrent update of the PTE. But that's too early for mmu_has_feature(), so when CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG is selected, mmu_has_feature() calls printk(). That's too early to call printk() because KASAN early zero shadow page is not set up yet. It leads to a deadlock. However, when kasan_early_init() is called, there is only one CPU running and no risk of concurrent PTE update. So __set_pte_at() can be called with the 'percpu' flag. With that flag set, the PTE is written directly instead of being written via pte_update(). Fixes: 4291d085b0b0 ("powerpc/32s: Make pte_update() non atomic on 603 core") Reported-by: Erhard Furtner <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/2ee707512b8b212b079b877f4ceb525a1606a3fb.1656655567.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/32: Set an IBAT covering up to _einittext during initChristophe Leroy2-8/+6
Always set an IBAT covering up to _einittext during init because when CONFIG_MODULES is not selected there is no reason to have an exception handler for kernel instruction TLB misses. It implies DBAT and IBAT are now totaly independent, IBATs are set by setibat() and DBAT by setbat(). This allows to revert commit 9bb162fa26ed ("powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE") Reported-by: Maxime Bizon <[email protected]> Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/32: Call mmu_mark_initmem_nx() regardless of data block mapping.Christophe Leroy2-5/+5
mark_initmem_nx() calls either mmu_mark_initmem_nx() or set_memory_attr() based on return from v_block_mapped() of _sinittext. But we can now handle text and data independently, so that text may be mapped by block even when data is mapped by pages. On the 8xx for instance, at startup 32Mbytes of memory are pinned in TLB. So the pinned entries need to go away for sinittext. In next patch a BAT will be set to also covers sinittext on book3s/32. So it will also be needed to call mmu_mark_initmem_nx() even when data above sinittext is not mapped with BATs. As this is highly dependent on the platform, call mmu_mark_initmem_nx() regardless of data block mapping. Then the platform will know what to do. Modify 8xx mmu_mark_initmem_nx() so that inittext mapping is modified only when pagealloc debug and kfence are not active, otherwise inittext is mapped with standard pages. And don't do anything on kernel text which is already mapped with PAGE_KERNEL_TEXT. Fixes: da1adea07576 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/db3fc14f3bfa6215b0786ef58a6e2bc1e1f964d7.1655202804.git.christophe.leroy@csgroup.eu
2022-07-27powerpc/mce: use early_cpu_to_node() in mce_init()Nicholas Piggin1-1/+1
cpu_to_node() is not yet available (setup_arch() is called before setup_per_cpu_areas() by start_kernel()). Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/64s: Remove spurious fault flushing for NMMUNicholas Piggin1-3/+23
Commit 6d8278c414cb2 ("powerpc/64s/radix: do not flush TLB on spurious fault") removed the TLB flush for spurious faults, except when a coprocessor (nest MMU) maps the address space. This is not needed because the NMMU workaround in the PTE permission upgrade paths prevents PTEs existing with less restrictive access permissions than their corresponding TLB entries have. Remove it and replace with a comment. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/64s: POWER10 nest MMU can upgrade PTE access authority without TLB flushNicholas Piggin2-17/+28
The nest MMU in POWER9 does not re-fetch the PTE in response to permission mismatch, contrary to the architecture[*] and unlike the core MMU. This requires a TLB flush before upgrading permissions of valid PTEs, for any address space with a coprocessor attached. Per (non-public) Nest MMU Workbook, POWER10 nest MMU conforms to the architecture in this regard, so skip the workaround. [*] See: Power ISA Version 3.1B, 6.10.1.2 Modifying a Translation Table Entry, Setting a Reference or Change Bit or Upgrading Access Authority (PTE Subject to Atomic Hardware Updates): "If the only change being made to a valid PTE that is subject to atomic hardware updates is to set the Reference or Change bit to 1 or to upgrade access authority, a simpler sequence suffices because the translation hardware will refetch the PTE if an access is attempted for which the only problems were reference and/or change bits needing to be set or insufficient access authority." Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/64s: POWER10 nest MMU does not require flush escalation workaroundNicholas Piggin1-3/+11
Per (non-public) Nest MMU Workbook, POWER10 and POWER9P NMMU does not cache PTEs in PWC, so does not require PWC flush to invalidate these translations. Skip the workaround on POWER10 and later. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc: add documentation for HWCAPsNicholas Piggin1-0/+234
Take the arm64 HWCAP documentation file and adjust it for powerpc. Signed-off-by: Nicholas Piggin <[email protected]> Reviewed-by: Segher Boessenkool <[email protected]> [mpe: Fix ARCH_2_05 comment, as noticed by Tulio.] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/vdso: Fix __kernel_sync_dicache sequence with coherent icacheNicholas Piggin1-0/+1
Processors with coherent icache require the sequence sync ; icbi ; isync to entire store->execute coherency. icbi (to any address) must be executed to ensure isync flushes the pipeline. See "POWER9 Processor User's Manual, 4.6.2.2 Instruction Cache Block Invalidate (icbi)" for details. __kernel_sync_dicache is missing icbi for the coherent icache path. Add it. Signed-off-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/pci: Add config option for using all 256 PCI busesPali Rohár2-0/+17
By default on PPC32 PCI bus numbers are unique across all PCI domains. So a system could have only 256 PCI buses independently of available PCI domains. This is due to filling DT property pci-OF-bus-map which does not support a multi-domain setup. On all powerpc platforms except chrp and powermac there is no DT property pci-OF-bus-map anymore and therefore it is possible on non-chrp/powermac platforms to avoid this limitation of maximum number of 256 PCI buses in a system even on multi-domain setup. But avoiding this limitation would mean that all PCI and PCIe devices would be present on completely different BDF addresses as every PCI domain starts numbering PCI bueses from zero (instead of the last bus number of previous enumerated PCI domain). Such change could break existing software which expects fixed PCI bus numbers. So add a new config option CONFIG_PPC_PCI_BUS_NUM_DOMAIN_DEPENDENT which enables this change. By default it is disabled. It causes the initial value of hose->first_busno to be zero. Signed-off-by: Pali Rohár <[email protected]> [mpe: Minor change log wording] Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/pci: Disable filling pci-OF-bus-map for non-chrp/powermacPali Rohár1-3/+10
Creating or filling pci-OF-bus-map property in the device-tree is deprecated since May 2006 [1] and was used only in old platforms like PowerMac. Currently kernel code handles it only for chrp and powermac code. So completely disable filling pci-OF-bus-map property for non-chrp and non-powermac platforms. [1] - https://lore.kernel.org/linuxppc-dev/[email protected]/ Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/pci: Hide pci_create_OF_bus_map() for non-chrp codePali Rohár2-0/+4
Function pci_create_OF_bus_map() is used only in chrp code. So hide it from all other platforms. Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/pci: Make pcibios_make_OF_bus_map() staticPali Rohár1-3/+1
Function pcibios_make_OF_bus_map() is used only in pci_32.c. So make it static. Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/pci: Hide pci_device_from_OF_node() for non-powermac codePali Rohár3-0/+6
Function pci_device_from_OF_node() is used only in powermac code. So hide it from all other platforms. Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc: dts: turris1x.dts: Add CPLD reboot nodePali Rohár1-1/+9
CPLD firmware can reset board by writing value 0x01 at CPLD memory offset 0x0d. Define syscon-reboot node for this reset support. Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers") Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27powerpc/fsl-pci: Fix Class Code of PCIe Root PortPali Rohár2-0/+9
By default old pre-3.0 Freescale PCIe controllers reports invalid PCI Class Code 0x0b20 for PCIe Root Port. It can be seen by lspci -b output on P2020 board which has this pre-3.0 controller: $ lspci -bvnn 00:00.0 Power PC [0b20]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) !!! Invalid class 0b20 for header type 01 Capabilities: [4c] Express Root Port (Slot-), MSI 00 Fix this issue by programming correct PCI Class Code 0x0604 for PCIe Root Port to the Freescale specific PCIe register 0x474. With this change lspci -b output is: $ lspci -bvnn 00:00.0 PCI bridge [0604]: Freescale Semiconductor Inc P2020E [1957:0070] (rev 21) (prog-if 00 [Normal decode]) Capabilities: [4c] Express Root Port (Slot-), MSI 00 Without any "Invalid class" error. So class code was properly reflected into standard (read-only) PCI register 0x08. Same fix is already implemented in U-Boot pcie_fsl.c driver in commit: http://source.denx.de/u-boot/u-boot/-/commit/d18d06ac35229345a0af80977a408cfbe1d1015b Fix activated by U-Boot stay active also after booting Linux kernel. But boards which use older U-Boot version without that fix are affected and still require this fix. So implement this class code fix also in kernel fsl_pci.c driver. Cc: [email protected] Signed-off-by: Pali Rohár <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.