- Jan 23, 2020
-
-
Christophe Leroy authored
This is copied and adapted from commit 5c929885 ("powerpc/vdso64: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE") from Santosh Sivaraj <santosh@fossix.org> Benchmark from vdsotest-all: clock-gettime-realtime: syscall: 3601 nsec/call clock-gettime-realtime: libc: 1072 nsec/call clock-gettime-realtime: vdso: 931 nsec/call clock-gettime-monotonic: syscall: 4034 nsec/call clock-gettime-monotonic: libc: 1213 nsec/call clock-gettime-monotonic: vdso: 1076 nsec/call clock-gettime-realtime-coarse: syscall: 2722 nsec/call clock-gettime-realtime-coarse: libc: 805 nsec/call clock-gettime-realtime-coarse: vdso: 668 nsec/call clock-gettime-monotonic-coarse: syscall: 2949 nsec/call clock-gettime-monotonic-coarse: libc: 882 nsec/call clock-gettime-monotonic-coarse: vdso: 745 nsec/call Additional test passed with: vdsotest -d 30 clock-gettime-monotonic-coarse verify Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://github.com/linuxppc/issues/issues/41 Link: https://lore.kernel.org/r/d1d24a376e396540194eeb85a2efe481e92ade24.1575273217.git.christophe.leroy@c-s.fr
-
Christophe Leroy authored
Commit 18ad51dd ("powerpc: Add VDSO version of getcpu") added getcpu() for PPC64 only, by making use of a user readable general purpose SPR. PPC32 doesn't have any such SPR. For non SMP, just return CPU id 0 from the VDSO directly. PPC32 doesn't support CONFIG_NUMA so NUMA node is always 0. Before the patch, vdsotest reported: getcpu: syscall: 1572 nsec/call getcpu: libc: 1787 nsec/call getcpu: vdso: not tested Now, vdsotest reports: getcpu: syscall: 1582 nsec/call getcpu: libc: 502 nsec/call getcpu: vdso: 187 nsec/call Signed-off-by:
-
Christophe Leroy authored
Since commit 0f0581b2 ("spi: fsl: Convert to use CS GPIO descriptors"), the prefered way to define chipselect GPIOs is using 'cs-gpios' property instead of the legacy 'gpios' property. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Christophe Leroy authored
8xx is now able to support any range length so range tests can be enabled. Signed-off-by:
-
Christophe Leroy authored
Unlike standard powerpc, Powerpc 8xx doesn't have SPRN_DABR, but it has a breakpoint support based on a set of comparators which allow more flexibility. Commit 4ad8622d ("powerpc/8xx: Implement hw_breakpoint") implemented breakpoints by emulating the DABR behaviour. It did this by setting one comparator the match 4 bytes at breakpoint address and the other comparator to match 4 bytes at breakpoint address + 4. Rewrite 8xx hw_breakpoint to make breakpoints match all addresses defined by the breakpoint address and length by making full use of comparators. Now, comparator E is set to match any address greater than breakpoint address minus one. Comparator F is set to match any address lower than breakpoint address plus breakpoint length. Addresses are aligned to 32 bits. When the breakpoint range starts at address 0, the breakpoint is set to match comparator F only. When the breakpoint range end at address 0xffffffff, the breakpoint is set to match comparator E only. Otherwise the breakpoint is set to match comparator E and F. At the same time, use registers bit names instead of hardcoded values. Signed-off-by:
-
Christophe Leroy authored
When not using large TLBs, the IMMR region is still mapped as a whole block in the FIXMAP area. Properly report that the IMMR region is block-mapped even when not using large TLBs. Signed-off-by:
-
Christophe Leroy authored
ptdump_check_wx() is called from mark_rodata_ro() which only exists when CONFIG_STRICT_KERNEL_RWX is selected. Fixes: 453d87f6 ("powerpc/mm: Warn if W+X pages found on boot") Signed-off-by:
-
Christophe Leroy authored
Verification cannot rely on simple bit checking because on some platforms PAGE_RW is 0, checking that a page is not W means checking that PAGE_RO is set instead of checking that PAGE_RW is not set. Use pte helpers instead of checking bits. Fixes: 453d87f6 ("powerpc/mm: Warn if W+X pages found on boot") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by:
-
Christophe Leroy authored
ptdump_check_wx() also have to be called when pages are mapped by blocks. Fixes: 453d87f6 ("powerpc/mm: Warn if W+X pages found on boot") Signed-off-by:
-
Christophe Leroy authored
Selecting CONFIG_PPC_DEBUG_WX only impacts ptdump and pgtable_32/64 init calls. Declaring related functions in asm/pgtable.h implies rebuilding almost everything. Move ptdump_check_wx() declaration in mm/mmu_decl.h Signed-off-by:
-
- Jan 16, 2020
-
-
Nicholas Piggin authored
This implements the tricky tracing and soft irq handling bits in C, leaving the low level bit to asm. A functional difference is that this redirects the interrupt exit to a return stub to execute blr, rather than the lr address itself. This is probably barely measurable on real hardware, but it keeps the link stack balanced. Tested with QEMU. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> [mpe: Move power4_fixup_nap back into exceptions-64s.S] Signed-off-by:
-
Julia Lawall authored
Mmgrab was introduced in commit f1f10076 ("mm: add new mmgrab() helper") and most of the kernel was updated to use it. Update a remaining file. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/ ) <smpl> @@ expression e; @@ - atomic_inc(&e->mm_count); + mmgrab(e); </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by:
-
Russell Currey authored
I have tested this with the Radix MMU and everything seems to work, and the previous patch for Hash seems to fix everything too. STRICT_KERNEL_RWX should still be disabled by default for now. Please test STRICT_KERNEL_RWX + RELOCATABLE! Signed-off-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
-
Russell Currey authored
With STRICT_KERNEL_RWX on in a relocatable kernel under the hash MMU, if the position the kernel is loaded at is not 16M aligned things go horribly wrong. Specifically hash__mark_initmem_nx() will call hash__change_memory_range() which then aligns down the start address, and due to the text not being 16M aligned causes some of the kernel text to be marked non-executable. We can avoid this when selecting the linear mapping size, so do so and print a warning. I tested this for various alignments and as long as the position is 64K aligned it's fine (the base requirement for powerpc). Signed-off-by:
-
- Jan 14, 2020
-
-
Pingfan Liu authored
In lmb_is_removable(), if a section is not present, it should continue to test the rest of the sections in the block. But the current code fails to do so. Fixes: 51925fb3 ("powerpc/pseries: Implement memory hotplug remove in the kernel") Cc: stable@vger.kernel.org # v4.1+ Signed-off-by:
Pingfan Liu <kernelfans@gmail.com> Signed-off-by:
-
Sukadev Bhattiprolu authored
ASDR is HV-privileged and must only be accessed in HV-mode. Fixes a Program Check (0x700) when xmon in a VM dumps SPRs. Fixes: d1e1b351 ("powerpc/xmon: Add ISA v3.0 SPRs to SPR dump") Cc: stable@vger.kernel.org # v4.14+ Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.ibm.com> Reviewed-by:
-
- Jan 07, 2020
-
-
Bai Yingjie authored
CPU like P4080 has 36bit physical address, its DDR physical start address can be configured above 4G by LAW registers. For such systems in which their physical memory start address was configured higher than 4G, we need also to write addr_h into the spin table of the target secondary CPU, so that addr_h and addr_l together represent a 64bit physical address. Otherwise the secondary core can not get correct entry to start from. Signed-off-by:
Bai Yingjie <byj.tea@gmail.com> Acked-by:
Scott Wood <oss@buserror.net> Signed-off-by:
-
Bai Yingjie authored
When CONFIG_RELOCATABLE=y is set, VIRT_PHYS_OFFSET is a 64bit variable, thus __pa() returns as 64bit value. But when CONFIG_RELOCATABLE=n, __pa() returns 32bit value. When CONFIG_PHYS_64BIT is set, __pa() should consistently return as 64bit value irrelevant to CONFIG_RELOCATABLE. So we'd make __pa() consistently return phys_addr_t, which is 64bit when CONFIG_PHYS_64BIT is set. Signed-off-by:
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes these changes is as follows: (http://coccinelle.lip6.fr/ ) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
-
Julia Lawall authored
Use resource_size rather than a verbose computation on the end and start fields. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/ ) <smpl> @@ struct resource ptr; @@ - (ptr.end - ptr.start + 1) + resource_size(&ptr) </smpl> Signed-off-by:
-
Julia Lawall authored
The mpic_ipi_chip and mpic_irq_ht_chip structures are only copied into other structures, so make them const. The opportunity for this change was found using Coccinelle. Signed-off-by:
-
- Jan 06, 2020
-
-
Sebastian Andrzej Siewior authored
With CONFIG_QUICC_ENGINE enabled and CONFIG_UCC_GETH + CONFIG_SERIAL_QE disabled we have an unused variable (np). The code won't compile with -Werror. Move the np variable to the block where it is actually used. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by:
-
Alexey Kardashevskiy authored
H_PUT_TCE_INDIRECT uses a shared page to send up to 512 TCE to a hypervisor in a single hypercall. This does not work for secure VMs as the page needs to be shared or the VM should use H_PUT_TCE instead. This disables H_PUT_TCE_INDIRECT by clearing the FW_FEATURE_PUT_TCE_IND feature bit so SVMs will map TCEs using H_PUT_TCE. This is not a part of init_svm() as it is called too late after FW patching is done and may result in a warning like this: [ 3.727716] Firmware features changed after feature patching! [ 3.727965] WARNING: CPU: 0 PID: 1 at (...)arch/powerpc/lib/feature-fixups.c:466 check_features+0xa4/0xc0 Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by:
Thiago Jung Bauermann <bauerman@linux.ibm.com> Tested-by:
-
Alexey Kardashevskiy authored
H_PUT_TCE_INDIRECT allows packing up to 512 TCE updates into a single hypercall; H_STUFF_TCE can clear lots in a single hypercall too. However, unlike H_STUFF_TCE (which writes the same TCE to all entries), H_PUT_TCE_INDIRECT uses a 4K page with new TCEs. In a secure VM environment this means sharing a secure VM page with a hypervisor which we would rather avoid. This splits the FW_FEATURE_MULTITCE feature into FW_FEATURE_PUT_TCE_IND and FW_FEATURE_STUFF_TCE. "hcall-multi-tce" in the "/rtas/ibm,hypertas-functions" device tree property sets both; the "multitce=off" kernel command line parameter disables both. This should not cause behavioural change. Signed-off-by:
-
Alexey Kardashevskiy authored
By default a pseries guest supports a H_PUT_TCE hypercall which maps a single IOMMU page in a DMA window. Additionally the hypervisor may support H_PUT_TCE_INDIRECT/H_STUFF_TCE which update multiple TCEs at once; this is advertised via the device tree /rtas/ibm,hypertas-functions property which Linux converts to FW_FEATURE_MULTITCE. FW_FEATURE_MULTITCE is checked when dma_iommu_ops is used; however the code managing the huge DMA window (DDW) ignores it and calls H_PUT_TCE_INDIRECT even if it is explicitly disabled via the "multitce=off" kernel command line parameter. This adds FW_FEATURE_MULTITCE checking to the DDW code path. This changes tce_build_pSeriesLP to take liobn and page size as the huge window does not have iommu_table descriptor which usually the place to store these numbers. Fixes: 4e8b0cf4 ("powerpc/pseries: Add support for dynamic dma windows") Signed-off-by:
-
Ram Pai authored
This reverts commit edea902c. At the time the change allowed direct DMA ops for secure VMs; however since then we switched on using SWIOTLB backed with IOMMU (direct mapping) and to make this work, we need dma_iommu_ops which handles all cases including TCE mapping I/O pages in the presence of an IOMMU. Fixes: edea902c ("powerpc/pseries/iommu: Don't use dma_iommu_ops on secure guests") Signed-off-by:
Ram Pai <linuxram@us.ibm.com> [aik: added "revert" and "fixes:"] Signed-off-by:
-
Michael Ellerman authored
Commit d4e58e59 ("powerpc/powernv: Enable POWER8 doorbell IPIs") added a select of PPC_DOORBELL to PPC_PSERIES, but it already had a select of PPC_DOORBELL. One is enough. Reported-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Peter Ujfalusi authored
dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
-
Oliver O'Halloran authored
With the previous patch applied pcibios_setup_device() will always be run when pcibios_bus_add_device() is called. There are several code paths where pcibios_setup_bus_device() is still called (the PowerPC specific PCI hotplug support is one) so with just the previous patch applied the setup can be run multiple times on a device, once before the device is added to the bus and once after. There's no need to run the setup in the early case any more so just remove it entirely. Signed-off-by:
Oliver O'Halloran <oohall@gmail.com> Tested-by:
-
Shawn Anastasio authored
Move PCI device setup from pcibios_add_device() and pcibios_fixup_bus() to pcibios_bus_add_device(). This ensures that platform-specific DMA and IOMMU setup occurs after the device has been registered in sysfs, which is a requirement for IOMMU group assignment to work This fixes IOMMU group assignment for hotplugged devices on pseries, where the existing behavior results in IOMMU assignment before registration. Thanks to Lukas Wunner <lukas@wunner.de> for the suggestion. Signed-off-by:
Shawn Anastasio <shawn@anastas.io> Tested-by:
-
Oliver O'Halloran authored
On pseries there is a bug with adding hotplugged devices to an IOMMU group. For a number of dumb reasons fixing that bug first requires re-working how VFs are configured on PowerNV. For background, on PowerNV we use the pcibios_sriov_enable() hook to do two things: 1. Create a pci_dn structure for each of the VFs, and 2. Configure the PHB's internal BARs so the MMIO range for each VF maps to a unique PE. Roughly speaking a PE is the hardware counterpart to a Linux IOMMU group since all the devices in a PE share the same IOMMU table. A PE also defines the set of devices that should be isolated in response to a PCI error (i.e. bad DMA, UR/CA, AER events, etc). When isolated all MMIO and DMA traffic to and from devicein the PE is blocked by the root complex until the PE is recovered by the OS. The requirement to block MMIO causes a giant headache because the P8 PHB generally uses a fixed mapping between MMIO addresses and PEs. As a result we need to delay configuring the IOMMU groups for device until after MMIO resources are assigned. For physical devices (i.e. non-VFs) the PE assignment is done in pcibios_setup_bridge() which is called immediately after the MMIO resources for downstream devices (and the bridge's windows) are assigned. For VFs the setup is more complicated because: a) pcibios_setup_bridge() is not called again when VFs are activated, and b) The pci_dev for VFs are created by generic code which runs after pcibios_sriov_enable() is called. The work around for this is a two step process: 1. A fixup in pcibios_add_device() is used to initialised the cached pe_number in pci_dn, then 2. A bus notifier then adds the device to the IOMMU group for the PE specified in pci_dn->pe_number. A side effect fixing the pseries bug mentioned in the first paragraph is moving the fixup out of pcibios_add_device() and into pcibios_bus_add_device(), which is called much later. This results in step 2. failing because pci_dn->pe_number won't be initialised when the bus notifier is run. We can fix this by removing the need for the fixup. The PE for a VF is known before the VF is even scanned so we can initialise pci_dn->pe_number pcibios_sriov_enable() instead. Unfortunately, moving the initialisation causes two problems: 1. We trip the WARN_ON() in the current fixup code, and 2. The EEH core clears pdn->pe_number when recovering a VF and relies on the fixup to correctly re-set it. The only justification for either of these is a comment in eeh_rmv_device() suggesting that pdn->pe_number *must* be set to IODA_INVALID_PE in order for the VF to be scanned. However, this comment appears to have no basis in reality. Both bugs can be fixed by just deleting the code. Tested-by: -
Aneesh Kumar K.V authored
Resource struct p->res is assigned later. Avoid using %pR before the resource struct is assigned. Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
-
Michael Ellerman authored
Userspace isn't allowed to access certain address ranges, make sure we actually test that to at least some degree. This would have caught the recent bug where the SLB fault handler was incorrectly called on an out-of-range access when using the Radix MMU. It also would have caught the bug we had in get_region_id() where we were inserting SLB entries for bad addresses. Signed-off-by:
-
Anju T Sudhakar authored
Documentation for IMC (In-Memory Collection Counters) infrastructure and trace-mode of IMC. Signed-off-by:
Anju T Sudhakar <anju@linux.vnet.ibm.com> [mpe: Convert to rst, minor rewording, make PMI example more concise] Signed-off-by:
-
Nathan Chancellor authored
Clang warns: ../arch/powerpc/boot/4xx.c:231:3: warning: misleading indentation; statement is not part of the previous 'else' [-Wmisleading-indentation] val = SDRAM0_READ(DDR0_42); ^ ../arch/powerpc/boot/4xx.c:227:2: note: previous statement is here else ^ This is because there is a space at the beginning of this line; remove it so that the indentation is consistent according to the Linux kernel coding style and clang no longer warns. Fixes: d23f5099 ("[POWERPC] 4xx: Adds decoding of 440SPE memory size to boot wrapper library") Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Jordan Niethe authored
In entry_64.S there are places that open code saving and restoring the non-volatile registers. There are already macros for doing this so use them. Signed-off-by:
Jordan Niethe <jniethe5@gmail.com> Reviewed-by:
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds authored
Pull RISC-V fixes from Paul Walmsley: "Several fixes for RISC-V: - Fix function graph trace support - Prefix the CSR IRQ_* macro names with "RV_", to avoid collisions with macros elsewhere in the Linux kernel tree named "IRQ_TIMER" - Use __pa_symbol() when computing the physical address of a kernel symbol, rather than __pa() - Mark the RISC-V port as supporting GCOV One DT addition: - Describe the L2 cache controller in the FU540 DT file One documentation update: - Add patch acceptance guideline documentation" * tag 'riscv/for-v5.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: Documentation: riscv: add patch acceptance guidelines riscv: prefix IRQ_ macro names with an RV_ namespace clocksource: riscv: add notrace to riscv_sched_clock riscv: ftrace: correct the condition logic in function graph tracer riscv: dts: Add DT support for SiFive L2 cache controller riscv: gcov: enable gcov for RISC-V riscv: mm: use __pa_symbol for kernel symbols
-
- Jan 05, 2020
-
-
Paul Walmsley authored
Formalize, in kernel documentation, the patch acceptance policy for arch/riscv. In summary, it states that as maintainers, we plan to only accept patches for new modules or extensions that have been frozen or ratified by the RISC-V Foundation. We've been following these guidelines for the past few months. In the meantime, we've received quite a bit of feedback that it would be helpful to have these guidelines formally documented. Based on a suggestion from Matthew Wilcox, we also add a link to this file to Documentation/process/index.rst, to make this document easier to find. The format of this document has also been changed to align to the format outlined in the maintainer entry profiles, in accordance with comments from Jon Corbet and Dan Williams. Signed-off-by:
Paul Walmsley <paul.walmsley@sifive.com> Reviewed-by:
Palmer Dabbelt <palmerdabbelt@google.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Krste Asanovic <krste@berkeley.edu> Cc: Andrew Waterman <waterman@eecs.berkeley.edu> Cc: Matthew Wilcox <willy@infradead.org> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net>
-
Paul Walmsley authored
"IRQ_TIMER", used in the arch/riscv CSR header file, is a sufficiently generic macro name that it's used by several source files across the Linux code base. Some of these other files ultimately include the arch/riscv CSR include file, causing collisions. Fix by prefixing the RISC-V csr.h IRQ_ macro names with an RV_ prefix. Fixes: a4c3733d ("riscv: abstract out CSR names for supervisor vs machine mode") Reported-by:
Olof Johansson <olof@lixom.net> Acked-by:
-
