- 26 Jul, 2016 1 commit
-
-
Michael Ellerman authored
The recent commit to rework the hash MMU setup broke the build when CONFIG_PPC_NATIVE=n. Fix it by adding an IS_ENABLED() check before calling hpte_init_native(). Removing the else clause opens the possibility that we don't set any ops, which would probably lead to a strange crash later. So add a check that we correctly initialised at least one member of the struct. Fixes: 166dd7d3 ("powerpc/64: Move MMU backend selection out of platform code") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Acked-by:
Michael Ellerman <mpe@ellerman.id.au>
-
- 21 Jul, 2016 31 commits
-
-
Alastair D'Silva authored
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by:
Alastair D'Silva <alastair@d-silva.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alastair D'Silva authored
This patch provides the necessary infrastructure to allow drivers to be automatically loaded via udev. It implements the minimum required to be able to use module_cpu_feature_match() to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed are a mirror of the cpu_user_features (converted to an offset from a mask). This decision was made to ensure that the behavior between features for module loading and userspace are consistent. Signed-off-by:
-
Alexey Kardashevskiy authored
The iommu_table_ops::exchange() callback writes new TCE to the table and returns old value and permission mask. The old TCE value is correctly converted from BE to CPU endian; however permission mask was calculated from BE value and therefore always returned DMA_NONE which could cause memory leak on LE systems using VFIO SPAPR TCE IOMMU v1 driver. This fixes pnv_tce_xchg() to have @oldtce a CPU endian. Fixes: 05c6cfb9 ("powerpc/iommu/powernv: Release replaced TCE") Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Sukadev Bhattiprolu authored
__hugepte_alloc() uses kmem_cache_zalloc() to allocate a zeroed PTE and proceeds to use the newly allocated PTE. Add a memory barrier to make sure that the other CPUs see a properly initialized PTE. Based on a fix suggested by James Dykman. Reported-by:
James Dykman <jdykman@us.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Tested-by:
-
Michael Ellerman authored
In the module loader we process relocations, and for long jumps we generate trampolines (aka stubs). At the call site for one of these trampolines we usually need to generate a load instruction to restore the TOC pointer into r2. There is one exception however, which is calls to mcount() using the mprofile-kernel ABI, they handle the TOC inside the stub, and so for them we do not generate a TOC load. The bug is in how the code in restore_r2() decides if it needs to generate the TOC load. It does so by looking for a nop following the branch, and if it sees a nop, it replaces it with the load. In general the compiler has no reason to generate a nop following the mcount() call and so that check works OK. However if we combine a jump label at the start of a function, with an early return, such that GCC applies the shrink-wrapping optimisation, we can then end up with an mcount call followed immediately by a nop. However the nop is not there for a TOC load, it is for the jump label. That confuses restore_r2() into replacing the jump label nop with a TOC load, which in turn confuses ftrace into replacing the mcount call with a b +8 (fixed in the previous commit). The end result is we jump over the jump label, which if it was supposed to return means we incorrectly run the body of the function. We have seen this in practice with some yet-to-be-merged patches that use jump labels more extensively. The fix is relatively simple, in restore_r2() we check for an mprofile-kernel style mcount() call first, before looking for the presence of a nop. Fixes: 15308664 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI") Signed-off-by:
-
Michael Ellerman authored
In __ftrace_make_nop() (the 64-bit version), we have code to deal with two ftrace ABIs. There is the original ABI, which looks mostly like a function call, and then the mprofile-kernel ABI which is just a branch. The code tries to handle both cases, by looking for the presence of a load to restore the TOC pointer (PPC_INST_LD_TOC). If we detect the TOC load, we assume the call site is for an mcount() call using the old ABI. That means we patch the mcount() call with a b +8, to branch over the TOC load. However if the kernel was built with mprofile-kernel, then there will never be a call site using the original ftrace ABI. If for some reason we do see a TOC load, then it's there for a good reason, and we should not jump over it. So split the code, using the existing CC_USING_MPROFILE_KERNEL. Kernels built with mprofile-kernel will only look for, and expect, the new ABI, and similarly for the original ABI. Signed-off-by: -
Benjamin Herrenschmidt authored
There is little enough differences now. mpe: Add a/p/k/setup.h to contain the prototypes and empty versions of functions we need, rather than using weak functions. Add a few other empty versions to avoid as many #ifdefs as possible in the code. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
Do it right after probe_machine() since it's about testing ppc_md, and put the test in the common code. Signed-off-by:
-
Benjamin Herrenschmidt authored
It makes more sense to do it before intializing xmon() as xmon might use the info in there. We do want to register the console early though in case we want some functioning printk's in the cpu map setup. Signed-off-by:
-
Benjamin Herrenschmidt authored
Matches 64-bit. Also move the call to the same spot as ppc64 Signed-off-by:
-
Benjamin Herrenschmidt authored
And kill setup_system(). Signed-off-by:
-
Benjamin Herrenschmidt authored
Also remove the completely osbolete comment. We *do* look in the device-tree. Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
It is now called right after platform probe, so the probe function can just do the job. Signed-off-by:
-
Benjamin Herrenschmidt authored
This converts all the 32-bit platforms to use the expanded device-tree which is a pretty mechanical change. Unlike 64-bit, the 32-bit kernel didn't rely on platform initializations to setup the MMU since it sets it up entirely before probe_machine() so the move has comparatively less consequences though it's a bigger patch. Signed-off-by:
-
Benjamin Herrenschmidt authored
We no long need the machine type that early, so we can move probe_machine() to after the device-tree has been expanded. This will allow further consolidation. Signed-off-by:
-
Benjamin Herrenschmidt authored
Anything in there will be overwritten, so it helps catching nasty bugs if we check that it's indeed full of NULL's before we do so. Signed-off-by:
-
Benjamin Herrenschmidt authored
Moving probe_machine() to after mmu init will cause the ppc_md fields relative to the hash table management to be overwritten. Since we have essentially disconnected the machine type from the hash backend ops, finish the job by moving them to a different structure. The only callback that didn't quite fix is update_partition_table since this is not specific to hash, so I moved it to a standalone variable for now. We can revisit later if needed. Signed-off-by:
-
Benjamin Herrenschmidt authored
pmac_declare_of_platform_devices() is already a machine initcall, thus it won't be called on a non-powermac machine. Testing for chrp there is pointless. Signed-off-by:
-
Benjamin Herrenschmidt authored
Instead, check for FW_FEATURE_SPLPAR. This should be roughtly equivalent as all pseries machiens that can have an HEA also support SPLPAR and no other machine type does. Signed-off-by:
-
Benjamin Herrenschmidt authored
Use the device-tree instead as we'll be moving probe_machine() out of early_setup Signed-off-by:
-
Benjamin Herrenschmidt authored
These days, memblocks is available later, so we can just allocate it as part of iob_init. Signed-off-by:
-
Benjamin Herrenschmidt authored
We move it into early_mmu_init() based on firmware features. For PS3, we have to move the setting of these into early_init_devtree(). Signed-off-by:
-
Benjamin Herrenschmidt authored
The SMU command buffer needs to be allocated below 2G using memblock. In the past, this had to be done very early from the arch code as memblock wasn't available past that point. That is no longer the case though, smu_init() is called from setup_arch() when memblock is still functional these days. So move the allocation to the SMU driver itself. Signed-off-by:
-
Benjamin Herrenschmidt authored
The various calls to establish exception endianness and AIL are now done from a single point using already established CPU and FW feature bits to decide what to do. Signed-off-by:
-
Benjamin Herrenschmidt authored
We move the function itself to pseries/firmware.c and call it along with almost all other flat device-tree parsers from early_init_devtree() Signed-off-by:
-
Benjamin Herrenschmidt authored
Instead of punching a hole in the linear mapping, just use normal cachable memory, and apply the flush sequence documented in the CPC625 (aka U3) user manual. This allows us to remove quite a bit of code related to the early allocation of the DART and the hole in the linear mapping. We can also get rid of the copy of the DART for suspend/resume as the original memory can just be saved/restored now, as long as we properly sync the caches. Signed-off-by:
-
Benjamin Herrenschmidt authored
There is really no need to do them that early, early_setup() runs before MMU is on, we should do the strict minimum there to get the MMU going. Signed-off-by:
-
Benjamin Herrenschmidt authored
Make it part of early_setup() as we really want the feature fixups to be applied before we turn on the MMU since they can have an impact on the various assembly path related to MMU management and interrupts. This makes 64-bit match what 32-bit does. Signed-off-by:
-
Benjamin Herrenschmidt authored
32 and 64-bit do a similar set of calls early on, we move it all to a single common function to make the boot code more readable. Signed-off-by:
-
- 20 Jul, 2016 2 commits
-
-
Benjamin Herrenschmidt authored
This provides an equivalent of of_fdt_match() for non-flat trees. This is more practical than matching an array of of_device_id structs when converting a bunch of existing users of of_fdt_match(). Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Tyrel Datwyler authored
The underlying slot hotplug registration code assumed multiple slots, but the actual implementation is broken for multiple slots. This went unnoticed for years do to the fact that PowerVM seems to only ever provide a single hotplug slot per PHB. Under qemu/kvm the hotplug slot model aligns more with x86 where multiple slots are presented under a single PHB. As seen in the following each additional slot after the first fails to register due to each slot always being compared against the first child node of the PHB in the device tree. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [Slot 0] registered rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 The registration logic is fixed so that each slot is compared against the existing child devices of the PHB in the device tree to determine present slots vs empty slots. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [C0] registered rpaphp: Slot [C1] registered rpaphp: Slot [C2] registered rpaphp: Slot [C3] registered rpaphp: Slot [C4] registered Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Reviewed-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> [mpe: Massage changelog] Signed-off-by:
-
- 19 Jul, 2016 6 commits
-
-
Kevin Hao authored
It is seldom used in the kernel code and can be easily replaced by either RELOCATABLE or PPC32. So there is no reason to keep a separate kernel option for this. Signed-off-by:
Kevin Hao <haokexin@gmail.com> Signed-off-by:
-
Kevin Hao authored
It makes no sense to keep two separate RELOCATABLE config entries for ppc32 and ppc64 respectively. Merge them into one and move it to a common place. Signed-off-by:
-
Kevin Hao authored
In the current code, the RELOCATABLE will be forcedly enabled when enabling CRASH_DUMP. But for ppc32, the RELOCABLE also depend on ADVANCED_OPTIONS and select NONSTATIC_KERNEL. This will cause the following build error when CRASH_DUMP=y && ADVANCED_OPTIONS=n because the select of NONSTATIC_KERNEL doesn't take effect. arch/powerpc/include/asm/io.h: In function 'virt_to_phys': arch/powerpc/include/asm/page.h:113:26: error: 'virt_phys_offset' undeclared (first use in this function) #define VIRT_PHYS_OFFSET virt_phys_offset ^ It doesn't have any strong reasons to make the RELOCATABLE depend on ADVANCED_OPTIONS. So remove this dependency to fix this issue. Signed-off-by: -
John Allen authored
The sysfs interface used to handle PowerVM hotplug events should use the hotplug queue as well. PRRN events will soon be placing many hotplug events on the queue at once and we will need ordinary hotplug events to use the queue as well in order to ensure these events will still be handled and that proper serialization is maintained during the PRRN event. Signed-off-by:
John Allen <jallen@linux.vnet.ibm.com> Reviewed-by:
-
John Allen authored
Add handler for new hotplug interrupt. For memory and CPU hotplug events, we will add the hotplug errorlog to the hotplug workqueue. Since PCI hotplug is not currently supported in the kernel, PCI hotplug events are written to the rtas_log_bug and are handled by rtas_errd. Signed-off-by:
-
John Allen authored
In support of PAPR changes to add a new hotplug interrupt, introduce a hotplug workqueue to avoid processing hotplug events in interrupt context. We will also take advantage of the queue on PowerVM to ensure hotplug events initiated from different sources (HMC and PRRN events) are handled and serialized properly. Signed-off-by:
-
