- 28 Jul, 2022 14 commits
-
-
Nayna Jain authored
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 <nayna@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220723113048.521744-2-nayna@linux.ibm.com
-
Alexey Kardashevskiy authored
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: 3c33066a ("powerpc/kernel/iommu: Add new iommu_table_in_use() helper") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
-
Alexey Kardashevskiy authored
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 authored
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: 381ceda8 ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") Signed-off-by:Hari Bathini <hbathini@linux.ibm.com> Signed-off-by:
-
Hari Bathini authored
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:
-
Michael Ellerman authored
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 <benh@kernel.crashing.org> Acked-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Christophe Leroy authored
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 authored
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:
-
Michael Ellerman authored
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 <lkp@intel.com> Signed-off-by:
-
Christophe Leroy authored
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 authored
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 52b1b46c ("of: Create platform devices for OF framebuffers") Include missing platform_device.h to allow cleaning asm/pci.h Fixes: 52b1b46c ("of: Create platform devices for OF framebuffers") Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Bagas Sanjaya authored
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 <sfr@canb.auug.org.au> Signed-off-by:
Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
-
Bagas Sanjaya authored
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: -
Bagas Sanjaya authored
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:
-
- 27 Jul, 2022 26 commits
-
-
Christophe Leroy authored
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 authored
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 authored
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 authored
Since commit 4bf4f42a ("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 <pali@kernel.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
-
Christophe Leroy authored
Commit 0e00a8c9 ("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: 0e00a8c9 ("powerpc: Allow CPU selection also on PPC32") Signed-off-by:
-
Christophe Leroy authored
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 authored
Add and use PPC_RAW_TRAP() instead of opencoding. Signed-off-by:
-
Christophe Leroy authored
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 authored
Commit 9850b6c6 ("arch: powerpc: Remove oprofile") removed oprofile. Remove all remaining parts of it. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Rashmica Gupta authored
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:
Rashmica Gupta <rashmica.g@gmail.com> Signed-off-by:
Madhavan Srinivasan <maddy@linux.vnet.ibm.com> [chleroy: Added power10 and fixed checkpatch issues] Reviewed-and-tested-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-and-tested-By: Kajol Jain <kjain@linux.ibm.com> [For 24x7 side changes] Signed-off-by:
-
Christophe Leroy authored
Since commit 4291d085 ("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: 4291d085 ("powerpc/32s: Make pte_update() non atomic on 603 core") Reported-by:
Erhard Furtner <erhard_f@mailbox.org> Signed-off-by:
-
Christophe Leroy authored
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 9bb162fa ("powerpc/603: Fix boot failure with DEBUG_PAGEALLOC and KFENCE") Reported-by:
Maxime Bizon <mbizon@freebox.fr> Signed-off-by:
-
Christophe Leroy authored
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: da1adea0 ("powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB") Signed-off-by:
-
Nicholas Piggin authored
cpu_to_node() is not yet available (setup_arch() is called before setup_per_cpu_areas() by start_kernel()). Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Nicholas Piggin authored
Commit 6d8278c4 ("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 authored
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 authored
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 authored
Take the arm64 HWCAP documentation file and adjust it for powerpc. Signed-off-by:
-
Nicholas Piggin authored
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:
-
Pali Rohár authored
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 authored
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/1148016268.13249.14.camel@localhost.localdomain/Signed-off-by:
-
Pali Rohár authored
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 authored
Function pcibios_make_OF_bus_map() is used only in pci_32.c. So make it static. Signed-off-by:
-
Pali Rohár authored
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 authored
CPLD firmware can reset board by writing value 0x01 at CPLD memory offset 0x0d. Define syscon-reboot node for this reset support. Fixes: 54c15ec3 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers") Signed-off-by:
-
Pali Rohár authored
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: stable@vger.kernel.org Signed-off-by:
-
