- 14 Jul, 2016 25 commits
-
-
Daniel Axtens authored
kvmppc_h_put_tce_indirect labels a u64 pointer as __user. It also labelled the u64 where get_user puts the result as __user. This isn't a pointer and so doesn't need to be labelled __user. Split the u64 value definition onto a new line to make it clear that it doesn't get the annotation. Signed-off-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au>
-
Anna-Maria Gleixner authored
The FROZEN transitions are used when a CPU suspends/resumes. In case of a suspend/resume, only the up prepare (CPU_UP_PREPARE_FROZEN) is handled. The error handling transition CPU_UP_CANCELED_FROZEN as well as the CPU_ONLINE_FROZEN transition are not handled. Masking the switch case action argument with ~CPU_TASKS_FROZEN, to handle all FROZEN tasks the same way than the corresponding non frozen tasks. Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Anna-Maria Gleixner <anna-maria@linutronix.de> Signed-off-by:
-
Andrew Donnellan authored
Add a new API, cxl_check_and_switch_mode() to allow for switching of bi-modal CAPI cards, such as the Mellanox CX-4 network card. When a driver requests to switch a card to CAPI mode, use PCI hotplug infrastructure to remove all PCI devices underneath the slot. We then write an updated mode control register to the CAPI VSEC, hot reset the card, and reprobe the card. As the card may present a different set of PCI devices after the mode switch, use the infrastructure provided by the pnv_php driver and the OPAL PCI slot management facilities to ensure that: * the old devices are removed from both the OPAL and Linux device trees * the new devices are probed by OPAL and added to the OPAL device tree * the new devices are added to the Linux device tree and probed through the regular PCI device probe path As such, introduce a new option, CONFIG_CXL_BIMODAL, with a dependency on the pnv_php driver. Refactor existing code that touches the mode control register in the regular single mode case into a new function, setup_cxl_protocol_area(). Co-authored-by:Ian Munsie <imunsie@au1.ibm.com> Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Andrew Donnellan authored
When calling pnv_php_set_slot_power_state() with state == OPAL_PCI_SLOT_OFFLINE, remove devices from the device tree as if we're dealing with OPAL_PCI_SLOT_POWER_OFF. Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: linux-pci@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Andrew Donnellan authored
The cxl driver will use infrastructure from pnv_php to handle device tree updates when switching bi-modal CAPI cards into CAPI mode. To enable this, export pnv_php_find_slot() and pnv_php_set_slot_power_state(), and add corresponding declarations, as well as the definition of struct pnv_php_slot, to asm/pnv-pci.h. Cc: Gavin Shan <gwshan@linux.vnet.ibm.com> Cc: linux-pci@vger.kernel.org Cc: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Ian Munsie authored
The CX4 card cannot cope with a context with PE=0 due to a hardware limitation, resulting in: [ 34.166577] command failed, status limits exceeded(0x8), syndrome 0x5a7939 [ 34.166580] mlx5_core 0000:01:00.1: Failed allocating uar, aborting Since the kernel API allocates a default context very early during device init that will almost certainly get Process Element ID 0 there is no easy way for us to extend the API to allow the Mellanox to inform us of this limitation ahead of time. Instead, work around the issue by extending the XSL structure to include a minimum PE to allocate. Although the bug is not in the XSL, it is the easiest place to work around this limitation given that the CX4 is currently the only card that uses an XSL. Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
-
Ian Munsie authored
The Mellanox CX4 in cxl mode uses a hybrid interrupt model, where interrupts are routed from the networking hardware to the XSL using the MSIX table, and from there will be transformed back into an MSIX interrupt using the cxl style interrupts (i.e. using IVTE entries and ranges to map a PE and AFU interrupt number to an MSIX address). We want to hide the implementation details of cxl interrupts as much as possible. To this end, we use a special version of the MSI setup & teardown routines in the PHB while in cxl mode to allocate the cxl interrupts and configure the IVTE entries in the process element. This function does not configure the MSIX table - the CX4 card uses a custom format in that table and it would not be appropriate to fill that out in generic code. The rest of the functionality is similar to the "Full MSI-X mode" described in the CAIA, and this could be easily extended to support other adapters that use that mode in the future. The interrupts will be associated with the default context. If the maximum number of interrupts per context has been limited (e.g. by the mlx5 driver), it will automatically allocate additional kernel contexts to associate extra interrupts as required. These contexts will be started using the same WED that was used to start the default context. Signed-off-by:
-
Ian Munsie authored
The Mellanox CX4 has a hardware limitation where only 4 bits of the AFU interrupt number can be passed to the XSL when sending an interrupt, limiting it to only 15 interrupts per context (AFU interrupt number 0 is invalid). In order to overcome this, we will allocate additional contexts linked to the default context as extra address space for the extra interrupts - this will be implemented in the next patch. This patch adds the preliminary support to allow this, by way of adding a linked list in the context structure that we use to keep track of the contexts dedicated to interrupts, and an API to simultaneously iterate over the related context structures, AFU interrupt numbers and hardware interrupt numbers. The point of using a single API to iterate these is to hide some of the details of the iteration from external code, and to reduce the number of APIs that need to be exported via base.c to allow built in code to call. Signed-off-by:
-
Ian Munsie authored
These APIs will be used by the Mellanox CX4 support. While they function standalone to configure existing behaviour, their primary purpose is to allow the Mellanox driver to inform the cxl driver of a hardware limitation, which will be used in a future patch. Signed-off-by:
-
Ian Munsie authored
This hooks up support for using the kernel API with a real PHB. After the AFU initialisation has completed it calls into the PHB code to pass it the AFU that will be used by other peer physical functions on the adapter. The cxl_pci_to_afu API is extended to work with peer PCI devices, retrieving the peer AFU from the PHB. This API may also now return an error if it is called on a PCI device that is not associated with either a cxl vPHB or a peer PCI device to an AFU, and this error is propagated down. Signed-off-by:
-
Ian Munsie authored
This adds support for the peer model of the cxl kernel api to the PowerNV PHB, in which physical function 0 represents the cxl function on the card (an XSL in the case of the CX4), which other physical functions will use for memory access and interrupt services. It is referred to as the peer model as these functions are peers of one another, as opposed to the Virtual PHB model which forms a hierarchy. This patch exports APIs to enable the peer mode, check if a PCI device is attached to a PHB in this mode, and to set and get the peer AFU for this mode. The cxl driver will enable this mode for supported cards by calling pnv_cxl_enable_phb_kernel_api(). This will set a flag in the PHB to note that this mode is enabled, and switch out it's controller_ops for the cxl version. The cxl version of the controller_ops struct implements it's own versions of the enable_device_hook and release_device to handle refcounting on the peer AFU and to allocate a default context for the device. Once enabled, the cxl kernel API may not be disabled on a PHB. Currently there is no safe way to disable cxl mode short of a reboot, so until that changes there is no reason to support the disable path. Signed-off-by:
-
Ian Munsie authored
The vPHB model of the cxl kernel API is a hierarchy where the AFU is represented by the vPHB, and it's AFU configuration records are exposed as functions under that vPHB. If there are no AFU configuration records we will create a vPHB with nothing under it, which is a waste of resources and will opt us into EEH handling despite not having anything special to handle. This also does not make sense for cards using the peer model of the cxl kernel API, where the other functions of the device are exposed via additional peer physical functions rather than AFU configuration records. This model will also not work with the existing EEH handling in the cxl driver, as that is designed around the vPHB model. Skip creating the vPHB for AFUs without any AFU configuration records, and opt out of EEH handling for them. Signed-off-by:
-
Ian Munsie authored
The cxl kernel API has a concept of a default context associated with each PCI device under the virtual PHB. The Mellanox CX4 will also use the cxl kernel API, but it does not use a virtual PHB - rather, the AFU appears as a physical function as a peer to the networking functions. In order to allow the kernel API to work with those networking functions, we will need to associate a default context with them as well. To this end, refactor the corresponding code to do this in vphb.c and export it so that it can be called from the PHB code. Signed-off-by:
-
Ian Munsie authored
The Mellanox CX4 uses a model where the AFU is one physical function of the device, and is used by other peer physical functions of the same device. This will require those other devices to grab a reference on the AFU when they are initialised to make sure that it does not go away during their lifetime. Move the AFU refcount functions to base.c so they can be called from the PHB code. Signed-off-by:
-
Ian Munsie authored
Devices that use CAPP DMA mode (such as the Mellanox CX4) require bus master to be enabled in order for the CAPI traffic to flow. This should be harmless to enable for other cxl devices, so unconditionally enable it in the adapter init flow. Signed-off-by:
-
Ian Munsie authored
This extends the check that the adapter is in a CAPI capable slot so that it may be called by external users in the kernel API. This will be used by the upcoming Mellanox CX4 support, which needs to know ahead of time if the card can be switched to cxl mode so that it can leave it in PCI mode if it is not. This API takes a parameter to check if CAPP DMA mode is supported, which it currently only allows on P8NVL systems, since that mode currently has issues accessing memory < 4GB on P8, and we cannot realistically avoid that. This API does not currently check if a CAPP unit is available (i.e. not already assigned to another PHB) on P8. Doing so would be racy since it is assigned on a first come first serve basis, and so long as CAPP DMA mode is not supported on P8 we don't need this, since the only anticipated user of this API requires CAPP DMA mode. Cc: Philippe Bergheaud <felix@linux.vnet.ibm.com> Signed-off-by:
-
Ian Munsie authored
The support for using the Mellanox CX4 in cxl mode will require additions to the PHB code. In preparation for this, move the existing cxl code out of pci-ioda.c into a separate pci-cxl.c file to keep things more organised. Signed-off-by:
-
Wei Yongjun authored
Use for_each_compatible_node() macro instead of open coding it. Generated by Coccinelle. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by:
-
Michael Ellerman authored
PROT_SAO is a powerpc-specific flag to mmap(), and we rely on arch specific logic to allow it to be passed to mmap(). Add a small test to ensure mmap() accepts PROT_SAO. We don't have a good way to test that it actually causes the mapping to be created with the right flags, so for now we just touch the mapping so it's faulted in. In future we might be able to do something better. Signed-off-by: -
Michael Ellerman authored
Signed-off-by: -
Michael Ellerman authored
Signed-off-by: -
Michael Ellerman authored
Purely to make it pleasing to the eye. Signed-off-by: -
Michael Ellerman authored
Signed-off-by: -
Michael Ellerman authored
None of these are used, or have been since we merged ppc & ppc64. Signed-off-by: -
Suraj Jitindar Singh authored
The array crash_shutdown_handles[] has size CRASH_HANDLER_MAX, thus when we loop over the elements of the list we check crash_shutdown_handles[i] && i < CRASH_HANDLER_MAX. However this means that when we increment i to CRASH_HANDLER_MAX we will perform an out of bound array access checking the first condition before exiting on the second condition. To avoid the out of bounds access, simply reorder the loop conditions. Fixes: 1d145165 ("powerpc: Add array bounds checking to crash_shutdown_handlers") Signed-off-by:
Suraj Jitindar Singh <sjitindarsingh@gmail.com> Reviewed-by:
-
- 13 Jul, 2016 6 commits
-
-
Benjamin Herrenschmidt authored
The subsequent test for RTAS along with the LPAR test are sufficient Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Benjamin Herrenschmidt authored
The test is unnecessary, the FW_FEATURE_LPAR is sufficient as there exist no other LPAR type that has RTAS. Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
Signed-off-by:
-
Benjamin Herrenschmidt authored
ge_imp3a_pic_init() is called way beyond the unflattening of the tree, it shouldn't be using of_flat_dt_* Signed-off-by:
-
Benjamin Herrenschmidt authored
Some bit of SPU code was using the FDT rather than the expanded device-tree. Fix it. Signed-off-by:
-
- 11 Jul, 2016 3 commits
-
-
Benjamin Herrenschmidt authored
The function is called by both 32-bit and 64-bit early setup right after early_init_devtree(). All it does is run yet another early DT parser which is precisely what early_init_devtree() is about, so move it in there. Signed-off-by:
-
Benjamin Herrenschmidt authored
Anything in early_setup() needs to be justified to be there, in this case, we need the trampolines before we can take exceptions and thus before we turn on the MMU. Also remove a pretty meaningless and misplaced debug message Signed-off-by:
-
Benjamin Herrenschmidt authored
early_init() is called in-place before kernel relocation and using whatever MMU setup exists at the point the kernel is entered. machine_init() is called after relocation and after some initial mapping of PAGE_OFFSET has been established (typically using BATs on 6xx/7xx/7xxx processors or some form of bolted TLB on others). Signed-off-by:
-
- 08 Jul, 2016 6 commits
-
-
Philippe Bergheaud authored
One should not attempt to switch a PHB into CAPI mode if there is a switch between the PHB and the adapter. This patch modifies the cxl driver to ignore CAPI adapters misplaced in switched slots. Signed-off-by:
Philippe Bergheaud <felix@linux.vnet.ibm.com> Reviewed-by:
-
Paul Gortmaker authored
The Kconfig/Makefile currently controlling compilation of this code is: drivers/misc/cxl/Kconfig:config CXL_BASE drivers/misc/cxl/Kconfig: bool drivers/misc/cxl/Makefile:obj-$(CONFIG_CXL_BASE) += base.o ...meaning that it currently is not being built as a module by anyone. Lets convert the one module_init into device_initcall so that when reading the driver it more clear that it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We don't replace module.h with init.h since the file is doing other modular stuff (module_get/put) even though it is built-in. Cc: Ian Munsie <imunsie@au1.ibm.com> Cc: Michael Neuling <mikey@neuling.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by:
-
Philippe Bergheaud authored
The PSL Slice Error Register (PSL_SERR_An) reports implementation dependent AFU errors, in the form of a bitmap. The PSL_SERR_An register content is printed in the form of hex dump debug message. This patch decodes the PSL_ERR_An register contents, and prints a specific error message for each possible error bit. It also dumps the secondary registers AFU_ERR_An and PSL_DSISR_An, that may contain extra debug information. This patch also removes the large WARN message that used to report the cxl slice error interrupt, and replaces it by a short informative message, that draws attention to AFU implementation errors. Signed-off-by:
-
Ian Munsie authored
If a kernel context is initialised and does not have any AFU interrupts allocated it will cause a NULL pointer dereference when the context is detached since the irq_names list will not have been initialised. Move the initialisation of the irq_names list into the cxl_context_init routine so that it will be valid for the entire lifetime of the context and will not cause a NULL pointer dereference. Signed-off-by:
-
Ian Munsie authored
An issue was noted in our debug logs where the XSL would leave the RA bit asserted after an AFU reset operation, which would effectively prevent further AFU reset operations from working. Workaround the issue by clearing the RA bit with an MMIO write if it is still asserted after any AFU control operation. Signed-off-by:
-
Ian Munsie authored
The AFU disable operation has a bug where it will not clear the enable bit and therefore will have no effect. To date this has likely been masked by fact that we perform an AFU reset before the disable, which also has the effect of clearing the enable bit, making the following disable operation effectively a noop on most hardware. This patch modifies the afu_control function to take a parameter to clear from the AFU control register so that the disable operation can clear the appropriate bit. This bug was uncovered on the Mellanox CX4, which uses an XSL rather than a PSL. On the XSL the reset operation will not complete while the AFU is enabled, meaning the enable bit was still set at the start of the disable and as a result this bug was hit and the disable also timed out. Because of this difference in behaviour between the PSL and XSL, this patch now makes the reset dependent on the card using a PSL to avoid waiting for a timeout on the XSL. It is entirely possible that we may be able to drop the reset altogether if it turns out we only ever needed it due to this bug - however I am not willing to drop it without further regression testing and have added comments to the code explaining the background. This also fixes a small issue where the AFU_Cntl register was read outside of the lock that protects it. Signed-off-by:
-
