RE: linux-4.5-rc4/arch/powerpc/boot/treeboot-akebono.c:90: possible bad test ?

Hello there Daniel, > That looks like a good suggestion: maybe make the test 'if (!emac)' > rather than explicitly comparing with zero. Righto. > Are you comfortable sending a patch to that effect? Sorry, no. My email provider can't implement the

Re: [RFC, kernel] powerpc/ioda: Set "read" permission when "write" is set

On 02/16/2016 02:18 PM, Michael Ellerman wrote: On Tue, 2016-12-01 at 04:40:20 UTC, Alexey Kardashevskiy wrote: Quite often drivers set only "write" permission assuming that this includes "read" permission as well and this works on plenty platforms. However IODA2 is strict about this and

[PATCH kernel v2] powerpc/ioda: Set "read" permission when "write" is set

Quite often drivers set only "write" permission assuming that this includes "read" permission as well and this works on plenty platforms. However IODA2 is strict about this and produces an EEH when "read" permission is not and reading happens. This adds a workaround in IODA code to always add the

Re: Fix BUG_ON() reporting in real mode on powerpc

> It might be a little better to do this: > > bugaddr = regs->nip; > if (REGION_ID(bugaddr) == 0 && !(regs->msr & MSR_IR)) > bugaddr += PAGE_OFFSET; > > It is possible to execute from addresses with the 0xc000... on top in > real mode, because

[RFC 2/2] selftests/powerpc: Add tests for various hash page fault paths

This new test case tries to create virtual memory scenarios to drive different types of hash page faults. It also uses perf API to capture the number of times it went through the intended hash fault paths. Signed-off-by: Anshuman Khandual --- Test result looks like

[RFC 1/2] powerpc/mm: Add trace points for various types of hash faults

This adds trace point definitions and invocations for all types of hash faults like THP, HugeTLB, 64K, 4K mappings. These are intended to be used in user space for performance and functional evaluation of various memory management paths. Signed-off-by: Anshuman Khandual

[PATCH] MAINTAINERS: Update EEH details and maintainership

Enhanced Error Handling could mean anything in the context of the entire kernel, so change the name to reference that it is both for PCI and powerpc. EEH covers a bit more than the previously listed files, so add the headers and platform-specific code to the EEH maintained section. In addition,

Re: [PATCH 2/2] powerpc: Add POWER9 cputable entry

On Wednesday 17 February 2016 10:37 AM, Michael Neuling wrote: > Add a cputable entry for POWER9. More code is required to actually > boot and run on a POWER9 but this gets the base piece in which we can > start building on. > > Copies over from POWER8 except for: > - Adds a new CPU_FTR_ARCH_30

[PATCH 2/2] powerpc: Add POWER9 cputable entry

Add a cputable entry for POWER9. More code is required to actually boot and run on a POWER9 but this gets the base piece in which we can start building on. Copies over from POWER8 except for: - Adds a new CPU_FTR_ARCH_30 bit to start hanging new architecture features from (in subsequent

[PATCH 1/2] powerpc/powernv: Create separate subcores CPU feature bit

Subcores isn't really part of the 2.07 architecture but currently we turn it on using the 2.07 feature bit. Subcores is really a POWER8 specific feature. This adds a new CPU_FTR bit just for subcores and moves the subcore init code over to use this. Signed-off-by: Michael Neuling

Re: Fix BUG_ON() reporting in real mode on powerpc

On Wed, Feb 17, 2016 at 03:43:11PM +1100, Balbir Singh wrote: > From: Balbir Singh > > I ran into this issue while debugging an early boot problem. > The system hit a BUG_ON() but report bug failed to print the > line number and file name. The reason being that the system

Fix BUG_ON() reporting in real mode on powerpc

From: Balbir Singh I ran into this issue while debugging an early boot problem. The system hit a BUG_ON() but report bug failed to print the line number and file name. The reason being that the system was running in real mode and report_bug() searches for addresses in the

Re: [PATCH v8 04/45] powerpc/powernv: Cleanup on pci_controller_ops instances

On 17/02/16 14:43, Gavin Shan wrote: This cleans up on below data struct instances to use tab instead of space indent of statement to avoid complains from scripts/checkpatch.pl. No logical changes introduced. @pnv_pci_ioda_controller_ops @pnv_npu_ioda_controller_ops Signed-off-by: Gavin

Re: [PATCH v8 33/45] powerpc/powernv: Simplify pnv_eeh_reset()

On 17/02/16 14:44, Gavin Shan wrote: This drops unnecessary nested if statements in pnv_eeh_reset() to improve the code readability. After the changes, the unused local variable "ret" is dropped as well. No logical changes introduced. Signed-off-by: Gavin Shan This

Re: [PATCH V11_RESEND 00/10] powerpc/perf: Enable SW branch filters

On Tue, 2016-02-16 at 14:08 +0100, Christophe Leroy wrote: > Your patches seem to be under review in Patchwork, see > https://patchwork.ozlabs.org/patch/526275/ > Why do you resend it ? Because I haven't *actually* got around to reviewing them. Or at least I started and found problems and

Re: [PATCH v8 03/45] powerpc/pci: Cleanup on struct pci_controller_ops

On 17/02/16 14:43, Gavin Shan wrote: Each PHB has one instance of "struct pci_controller_ops", which includes various callbacks called by PCI subsystem. In the definition of this struct, some callbacks have explicit names for its arguments, but the left don't have. This adds all explicit names

Re: [PATCH V11_RESEND 00/10] powerpc/perf: Enable SW branch filters

On 02/16/2016 06:38 PM, Christophe Leroy wrote: > Your patches seem to be under review in Patchwork, see > https://patchwork.ozlabs.org/patch/526275/ > Why do you resend it ? Its been 3-4 months I had posted last version V11. Wanted to check if it all works till now. So rebased the series, tested

[PATCH v8 16/45] powerpc/powernv: Remove DMA32 PE list

PEs are put into PHB DMA32 list (phb->ioda.pe_dma_list) according to their DMA32 weight. The PEs on the list are iterated to setup their TCE32 tables at system booting time. The list is used for once and there is for keep having it. This moves the logic calculating DMA32 weight of PHB and PE to

[PATCH v8 09/45] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg()

The original implementation of pnv_ioda_setup_pe_seg() configures IO and M32 segments by separate logics, which can be merged by by caching @segmap, @seg_size, @win in advance. This shouldn't cause any behavioural changes. Signed-off-by: Gavin Shan ---

[PATCH v8 21/45] powerpc/powernv: Create PEs at PCI hot plugging time

Currently, the PEs and their associated resources are assigned in ppc_md.pcibios_fixup() except those used by SRIOV VFs. The function is called for once after PCI probing and resources assignment is completed. So it isn't hotplug friendly. This creates PEs dynamically by

[PATCH v8 22/45] powerpc/powernv/ioda1: Support releasing IODA1 TCE table

pnv_pci_ioda_table_free_pages() can be reused to release the IODA1 TCE table when releasing IODA1 PE in subsequent patches. This renames the following functions to support releasing IODA1 TCE table: pnv_pci_ioda2_table_free_pages() to pnv_pci_ioda_table_free_pages(),

[PATCH v8 27/45] powerpc/pci: Export pci_add_device_node_info()

This renames update_dn_pci_info() to pci_add_device_node_info() with corresponding adjustment on the parameter type and exports it. The function is used to create pdn (struct pci_dn) for the indicated device node. Another function add_pdn(), almost wrapper of pci_add_device_node_info(), to be used

[PATCH v8 23/45] powerpc/powernv: Dynamically release PEs

This support releasing PEs dynamically. Firstly, this moves pnv_pci_ioda2_release_dma_pe() around, which is called to release DMA resource on releasing IODA2 PE. Secondly, several functions are implemented to release the consumed resources on releasing the PE: * pnv_pci_ioda1_unset_window() to

[PATCH v8 24/45] powerpc/pci: Rename pcibios_{add, remove}_pci_devices()

This renames pcibios_{add,remove}_pci_devices() to avoid conflicts with names of the weak functions in PCI subsystem, which have the prefix "pcibios". No logical changes introduced. Signed-off-by: Gavin Shan --- arch/powerpc/include/asm/pci-bridge.h | 4 ++--

[PATCH v8 04/45] powerpc/powernv: Cleanup on pci_controller_ops instances

This cleans up on below data struct instances to use tab instead of space indent of statement to avoid complains from scripts/checkpatch.pl. No logical changes introduced. @pnv_pci_ioda_controller_ops @pnv_npu_ioda_controller_ops Signed-off-by: Gavin Shan

[PATCH v8 20/45] powerpc/powernv: Allocate PE# in reverse order

PE number for one particular PE can be allocated dynamically or reserved according to the consumed M64 (64-bits prefetchable) segments of the PE. The M64 resources, and hence their segments and PE number are assigned/reserved in ascending order. The PE numbers are allocated dynamically in

[PATCH v8 25/45] powerpc/pci: Rename pcibios_find_pci_bus()

This renames pcibios_find_pci_bus() to pci_find_bus_by_node() to avoid conflicts with those PCI subsystem weak function names, which have prefix "pcibios". No logical changes introduced. Signed-off-by: Gavin Shan --- arch/powerpc/include/asm/pci-bridge.h | 2 +-

[PATCH v8 42/45] drivers/of: Rename unflatten_dt_node()

This renames unflatten_dt_node() to unflatten_dt_nodes() as it populates multiple device nodes from FDT blob. No logical changes introduced. Signed-off-by: Gavin Shan --- drivers/of/fdt.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git

[PATCH v8 31/45] powerpc/pci: Don't scan empty slot

In hotplug case, function pci_add_pci_devices() is called to rescan the specified PCI bus, which might not have any child devices. Access to the PCI bus's child device node will cause kernel crash without exception. This adds one more check to skip scanning PCI bus that doesn't have any

[PATCH v8 11/45] powerpc/powernv: Track M64 segment consumption

When unplugging PCI devices, their parent PEs might be offline. The consumed M64 resource by the PEs should be released at that time. As we track M32 segment consumption, this introduces an array to the PHB to track the mapping between M64 segment and PE number. Signed-off-by: Gavin Shan

[PATCH v8 05/45] powerpc/powernv: Drop phb->bdfn_to_pe()

This drops struct pnv_phb::bdfn_to_pe() as nobody uses it. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/pci-ioda.c | 9 - arch/powerpc/platforms/powernv/pci.h | 1 - 2 files changed, 10 deletions(-) diff --git

[PATCH v8 35/45] powerpc/powernv: Fundamental reset in pnv_pci_reset_secondary_bus()

In pnv_pci_reset_secondary_bus(), we should issue fundamental reset if any one subordinate device of the specified bus is requesting that. Otherwise, the device might not come up after the reset. Signed-off-by: Gavin Shan ---

[PATCH v8 38/45] powerpc/powernv: Functions to get/set PCI slot status

This exports 4 functins, which base on the corresponding OPAL APIs to get/set PCI slot status. Those functions are going to be used by PowerNV PCI hotplug driver: pnv_pci_get_device_tree()opal_get_device_tree() pnv_pci_get_presence_state() opal_pci_get_presence_state()

[PATCH v8 17/45] powerpc/powernv/ioda1: Improve DMA32 segment track

In current implementation, the DMA32 segments required by one specific PE isn't calculated with the information hold in the PE independently. It conflicts with the PCI hotplug design: PE centralized, meaning the PE's DMA32 segments should be calculated from the information hold in the PE

[PATCH v8 44/45] drivers/of: Return allocated memory from of_fdt_unflatten_tree()

This returns the allocate memory chunk, storing the unflattened device tree, from of_fdt_unflatten_tree() so that memory chunk can be released on demand in PowerNV PCI hotplug driver. Signed-off-by: Gavin Shan Acked-by: Rob Herring ---

[PATCH v8 43/45] drivers/of: Specify parent node in of_fdt_unflatten_tree()

This adds one more argument to of_fdt_unflatten_tree() to specify the parent node of the FDT blob that is going to be unflattened. In the result, the function can be used to unflatten FDT blob that represents device sub-tree in PowerNV PCI hotplug driver. Cc: Jyri Sarha

[PATCH v8 12/45] powerpc/powernv: Rename M64 related functions

This renames those functions picking PE number based on consumed M64 segments, mapping M64 segments to PEs as those functions are going to be shared by IODA1/IODA2 in next patch. No logical changes introduced. Signed-off-by: Gavin Shan ---

[PATCH v8 39/45] powerpc/powernv: Select OF_DYNAMIC

The device tree will change dynamically in PowerNV PCI hotplug driver. This enables CONFIG_OF_DYNAMIC to support that. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v8 45/45] PCI/hotplug: PowerPC PowerNV PCI hotplug driver

This adds standalone driver to support PCI hotplug for PowerPC PowerNV platform that runs on top of skiboot firmware. The firmware identifies hotpluggable slots and marked their device tree node with proper "ibm,slot-pluggable" and "ibm,reset-by-firmware". The driver scans device tree nodes to

[PATCH v8 19/45] powerpc/powernv: Use PE instead of number during setup and release

In current implementation, the PEs that are allocated or picked from the reserved list are identified by PE number. The PE instance has to be picked according to the PE number eventually. We have same issue when PE is released. For pnv_ioda_pick_m64_pe() and pnv_ioda_alloc_pe(), this returns PE

[PATCH v8 13/45] powerpc/powernv/ioda1: M64 support on P7IOC

This enables M64 window on P7IOC, which has been enabled on PHB3. Different from PHB3 where 16 M64 BARs are supported and each of them can be owned by one particular PE# exclusively or divided evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each of them are divided to 8 segments. So

[PATCH v8 34/45] powerpc/powernv: Exclude root bus in pnv_pci_reset_secondary_bus()

The function pnv_pci_reset_secondary_bus() is called like below. It's impossible for call the function on root bus. So it's safe to remove the root bus case in the function. No functional changes introduced. pci_parent_bus_reset() / pci_bus_reset() / pci_try_reset_bus()

[PATCH v8 37/45] powerpc/powernv: Use firmware PCI slot reset infrastructure

The skiboot firmware might provide the PCI slot reset capability which is identified by property "ibm,reset-by-firmware" on the PCI slot associated device node. This checks the property. If it exists, the reset request is routed to firmware. Otherwise, the reset is done by kernel as before.

[PATCH v8 30/45] powerpc/pci: Delay populating pdn

The pdn (struct pci_dn) instances are allocated from memblock or bootmem when creating PCI controller (hoses) in setup_arch(). PCI hotplug, which will be supported by proceeding patches, releases PCI device nodes and their corresponding pdn on unplugging event. The memory chunks for pdn instances

[PATCH v8 40/45] drivers/of: Split unflatten_dt_node()

The function unflatten_dt_node() is called recursively to unflatten device nodes and properties in the FDT blob. It looks complicated and hard to be understood. This splits the function into 3 functions: populate_properties(), populate_node() and unflatten_dt_node(). populate_properties(), which

[PATCH v8 14/45] powerpc/powernv/ioda1: Rename pnv_pci_ioda_setup_dma_pe()

This renames pnv_pci_ioda_setup_dma_pe() to pnv_pci_ioda1_setup_dma_pe() as it's the counter-part of IODA2's pnv_pci_ioda2_setup_dma_pe(). No logical changes introduced. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/pci-ioda.c | 9 + 1 file

[PATCH v8 06/45] powerpc/powernv: Reorder fields in struct pnv_phb

This moves those fields in struct pnv_phb that are related to PE allocation around. No logical change. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/pci.h | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH v8 10/45] powerpc/powernv: IO and M32 mapping based on PCI device resources

Currently, the IO and M32 segments are mapped to the corresponding PE based on the windows of the parent bridge of PE's primary bus. It's not going to work when the windows of root port or upstream port of the PCIe switch behind root port are extended to PHB's apertures in order to support hotplug

[PATCH v8 26/45] powerpc/pci: Move pci_find_bus_by_node() around

This moves pci_find_bus_by_node() from arch/powerpc/platforms/ pseries/pci_dlpar.c to arch/powerpc/kernel/pci-hotplug.c so that the function can be used by pSeries and PowerNV platform at the same time. Also, below cleanup applied. No functional changes introduced. * Remove variable "busdn" in

[PATCH v8 18/45] powerpc/powernv: Increase PE# capacity

Each PHB maintains an array helping to translate 2-bytes Request ID (RID) to PE# with the assumption that PE# takes one byte, meaning that we can't have more than 256 PEs. However, pci_dn->pe_number already had 4-bytes for the PE#. This extends the PE# capacity for every PHB. After that, the PE

[PATCH v8 36/45] powerpc/powernv: Support PCI slot ID

PowerNV platforms runs on top of skiboot firmware that includes changes to support PCI slots. PCI slots are identified by PHB's ID or the combo of that and PCI slot ID. This changes the EEH PowerNV backend to support PCI slots: * Rename arguments of opal_pci_reset() and opal_pci_poll(). *

[PATCH v8 41/45] drivers/of: Avoid recursively calling unflatten_dt_node()

In current implementation, unflatten_dt_node() is called recursively to unflatten device nodes in FDT blob. It's stress to limited stack capacity, especially to adopt the function to unflatten device sub-tree that possibly has multiple root nodes. In that case, we runs out of stack and the system

[PATCH v8 28/45] powerpc/pci: Introduce pci_remove_device_node_info()

This implements and exports pci_remove_device_node_info(). It's used to remove the pdn (struct pci_dn) for the indicated device node. The function is going to be used by PowerNV PCI hotplug driver. Signed-off-by: Gavin Shan --- arch/powerpc/include/asm/pci-bridge.h |

[PATCH v8 33/45] powerpc/powernv: Simplify pnv_eeh_reset()

This drops unnecessary nested if statements in pnv_eeh_reset() to improve the code readability. After the changes, the unused local variable "ret" is dropped as well. No logical changes introduced. Signed-off-by: Gavin Shan ---

[PATCH v8 29/45] powerpc/pci: Export pci_traverse_device_nodes()

This renames traverse_pci_devices() to pci_traverse_device_nodes(). The function traverses all subordinate device nodes of the specified one. Also, below cleanup applied to the function. No logical changes introduced. * Rename "pre" to "fn". * Avoid assignment in if condition reported from

[PATCH v8 32/45] powerpc/pci: Update bridge windows on PCI plug

On the PCI plugging event, PCI slot's subordinate devices are scanned and their (IO and MMIO) resources are assigned. Platform dependent resources (PE#, IO/MMIO/DMA windows) are allocated or created on updating windows of the slot's upstream bridge. This updates the windows of the hot plugged

[PATCH v8 15/45] powerpc/powernv/ioda1: Introduce PNV_IODA1_DMA32_SEGSIZE

Currently, there is one macro (TCE32_TABLE_SIZE) representing the TCE table size for one DMA32 segment. The constant representing the DMA32 segment size (1 << 28) is still used in the code. This defines PNV_IODA1_DMA32_SEGSIZE representing one DMA32 segment size. the TCE table size can be

[PATCH v8 08/45] powerpc/powernv: Fix initial IO and M32 segmap

There are two arrays for IO and M32 segment maps on every PHB. The index of the arrays are segment number and the value stored in the corresponding element is PE number, indicating the segment is assigned to the PE. Initially, all elements in those two arrays are zeroes, meaning all segments are

[PATCH v8 07/45] powerpc/powernv: Rename PE# fields in struct pnv_phb

This renames the fields related to PE number in "struct pnv_phb" for better reflecting of their usages as Alexey suggested. No logical changes introduced. Signed-off-by: Gavin Shan --- arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-

[PATCH v8 02/45] powerpc/pci: Override pcibios_setup_bridge()

This overrides pcibios_setup_bridge() that is called to update PCI bridge windows when PCI resource assignment is completed, to assign PE and setup various (resource) mapping for the PE in subsequent patches. Signed-off-by: Gavin Shan ---

[PATCH v8 01/45] PCI: Add pcibios_setup_bridge()

Currently, PowerPC PowerNV platform utilizes ppc_md.pcibios_fixup(), which is called for once after PCI probing and resource assignment are completed, to allocate platform required resources for PCI devices: PE#, IO and MMIO mapping, DMA address translation (TCE) table etc. Obviously, it's not

[PATCH v8 03/45] powerpc/pci: Cleanup on struct pci_controller_ops

Each PHB has one instance of "struct pci_controller_ops", which includes various callbacks called by PCI subsystem. In the definition of this struct, some callbacks have explicit names for its arguments, but the left don't have. This adds all explicit names of the arguments to the callbacks in

[PATCH v8 00/45] powerpc/powernv: PCI hotplug support

This series of patches rebases on powerpc/next branch, plus below additional patches: https://patchwork.ozlabs.org/patch/581315/ (PATCH[1/9] Richard's SRIOV EEH) https://patchwork.ozlabs.org/patch/582639/ (PATCH[1/1] Gavin's EEH fix) https://patchwork.ozlabs.org/patch/582093/

Re: [PATCH v8 8/8] livepatch: Detect offset for the ftrace location during build

On Tue, 2016-02-16 at 14:57 +0100, Petr Mladek wrote: > > Some dugging has shown an Oops in the fucntion int_to_scsilun() > called from ibmvscsi_queuecommand(). So, I rebooted and > did the following test: > > $> echo ibmvscsi_queuecommand >/sys/kernel/debug/tracing/set_ftrace_filter > $> echo

Re: [PATCH v2 3/7] ibmvscsi: Replace magic values in set_adpater_info() with defines

> "Tyrel" == Tyrel Datwyler writes: >> Is there some reason you didn't carry the review tag over from this: >> >> http://mid.gmane.org/20160204084459.gw27...@c203.arch.suse.de >> >> ? >> >> James Tyrel> The patch is slightly changed from v1. A define for AIX os

Re: [PATCH] MAINTAINERS: rename EEH from "enhanced" to "extended" error handling

On Wed, 2016-02-17 at 10:49 +1100, Russell Currey wrote: > On Wed, 2016-02-17 at 09:58 +1100, Gavin Shan wrote: > > On Wed, Feb 17, 2016 at 09:49:08AM +1100, Gavin Shan wrote: > > > > > > On Tue, Feb 16, 2016 at 07:52:00PM +1100, Russell Currey wrote: > > > > > > > > Incredibly, IBM online

Re: [PATCH] MAINTAINERS: rename EEH from "enhanced" to "extended" error handling

On Wed, 2016-02-17 at 10:49 +1100, Russell Currey wrote: > On Wed, 2016-02-17 at 09:58 +1100, Gavin Shan wrote: > > > > On Wed, Feb 17, 2016 at 09:49:08AM +1100, Gavin Shan wrote: > > > > > > > > > On Tue, Feb 16, 2016 at 07:52:00PM +1100, Russell Currey wrote: > > > > > > > > > > > >

[PATCH 2/2] powerpc/perf/24x7: Eliminate domain suffix in event names

From 1520e8087d047e8ab6c1bda027a74eb33956e5a0 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Tue, 16 Feb 2016 22:21:25 -0500 Subject: [PATCH 2/2] powerpc/perf/24x7: Eliminate domain suffix in event names The Physical Core events of the 24x7 PMU can be

[PATCH 1/2] powerpc/perf/hv-24x7: Display domain indices in sysfs

From aff5a822e873522b9a3f355f816547394b452a64 Mon Sep 17 00:00:00 2001 From: Sukadev Bhattiprolu Date: Tue, 16 Feb 2016 20:07:51 -0500 Subject: [PATCH 1/2] powerpc/perf/hv-24x7: Display domain indices in sysfs To help users determine domains, display the domain

Re: [PATCH] powerpc/eeh: rename EEH from "extended" to "enhanced" error handling

On Tue, Feb 16, 2016 at 11:06:05PM +1100, Russell Currey wrote: >IBM online documentation for EEH uses "extended error handling" and >"enhanced error handling" to refer to the same thing, in different >places. The only place mentioning it as "enhanced error handling" in the >kernel is the

Re: [PATCH] MAINTAINERS: rename EEH from "enhanced" to "extended" error handling

On Wed, Feb 17, 2016 at 09:49:08AM +1100, Gavin Shan wrote: >On Tue, Feb 16, 2016 at 07:52:00PM +1100, Russell Currey wrote: >>Incredibly, IBM online documentation for EEH uses "extended error handling" >>and "enhanced error handling" to refer to the same thing, in different >>places. In other

Re: [PATCH] MAINTAINERS: rename EEH from "enhanced" to "extended" error handling

On Tue, Feb 16, 2016 at 07:52:00PM +1100, Russell Currey wrote: >Incredibly, IBM online documentation for EEH uses "extended error handling" >and "enhanced error handling" to refer to the same thing, in different >places. In other parts of the kernel, namely the EEH documentation (found >in

Re: linux-4.5-rc4/arch/powerpc/boot/treeboot-akebono.c:90: possible bad test ?

Hi David, > > [linux-4.5-rc4/arch/powerpc/boot/treeboot-akebono.c:90]: (style) A pointer > can not be negative so it is either pointless or an error to check if it is > not. > > Source code is > >     emac = finddevice("/plb/opb/ethernet"); >     if (emac> 0) { > > but > >     void *emac; > >

Re: [PATCH] add POWER Virtual Management Channel driver

On Tue, Feb 16, 2016 at 02:43:13PM -0600, Steven Royer wrote: > From: Steven Royer > > The ibmvmc driver is a device driver for the POWER Virtual Management > Channel virtual adapter on the PowerVM platform. It is used to > communicate with the hypervisor for virtualization

Re: Question about code which uses MPIC_NO_RESET on 85XX

On Thu, 2016-02-04 at 14:56 +0100, Alessio Igor Bogani wrote: > Hi, > > Can we change this code (from mpc85xx_ds.c) > > if (of_flat_dt_is_compatible(root, "fsl,MPC8572DS-CAMP")) { > mpic = mpic_alloc(NULL, 0, > MPIC_NO_RESET | > MPIC_BIG_ENDIAN | >

[PATCH v4 18/18] cxl: Add tracepoints around the CAPI hcall

From: Christophe Lombard To ease debugging, add a few tracepoints around the CAPI hcalls. Co-authored-by: Frederic Barrat Signed-off-by: Frederic Barrat Signed-off-by: Christophe Lombard

[PATCH v4 17/18] cxl: Adapter failure handling

From: Christophe Lombard Check the AFU state whenever an API is called. The hypervisor may issue a reset of the adapter when it detects a fault. When it happens, it launches an error recovery which will either move the AFU to a permanent failure state, or in the

[PATCH v4 14/18] cxl: Support to flash a new image on the adapter from a guest

From: Christophe Lombard The new flash.c file contains the logic to flash a new image on the adapter, through a hcall. It is an iterative process, with chunks of data of 1M at a time. There are also 2 phases: write and verify. The flash operation itself is driven

[PATCH v4 15/18] cxl: Parse device tree and create CAPI device(s) at boot

Add new entry point to scan the device tree at boot in a guest, looking for CAPI devices. Co-authored-by: Christophe Lombard Signed-off-by: Frederic Barrat Signed-off-by: Christophe Lombard Acked-by: Ian

[PATCH v4 16/18] cxl: Support the cxl kernel API from a guest

Like on bare-metal, the cxl driver creates a virtual PHB and a pci device for the AFU. The configuration space of the device is mapped to the configuration record of the AFU. Reuse the code defined in afu_cr_read8|16|32() when reading the configuration space of the AFU device. Even though the

[PATCH v4 13/18] cxl: sysfs support for guests

From: Christophe Lombard Filter out a few adapter parameters which don't make sense in a guest. Document the changes. Co-authored-by: Frederic Barrat Signed-off-by: Frederic Barrat Signed-off-by: Christophe

[PATCH v4 12/18] cxl: Add guest-specific code

From: Christophe Lombard The new of.c file contains code to parse the device tree to find out about CAPI adapters and AFUs. guest.c implements the guest-specific callbacks for the backend API. The process element ID is not known until the context is attached, so we

[PATCH v4 11/18] cxl: Separate bare-metal fields in adapter and AFU data structures

From: Christophe Lombard Introduce sub-structures containing the bare-metal specific fields in the structures describing the adapter (struct cxl) and AFU (struct cxl_afu). Update all their references. Co-authored-by: Frederic Barrat

[PATCH v4 10/18] cxl: New hcalls to support CAPI adapters

From: Christophe Lombard The hypervisor calls provide an interface with a coherent plaform facility and function. It matches version 0.16 of the 'PAPR changes' document. The following hcalls are supported: H_ATTACH_CA_PROCESSAttach a process element to a

[PATCH v4 09/18] cxl: New possible return value from hcall

From: Christophe Lombard The hcalls introduced for CAPI use a possible new value: H_STATE (invalid state). Co-authored-by: Frederic Barrat Signed-off-by: Frederic Barrat Signed-off-by: Christophe Lombard

[PATCH v4 08/18] cxl: IRQ allocation for guests

The PSL interrupt is not going to be multiplexed in a guest, so an interrupt will be allocated for it for each context. It will still be the first interrupt found in the first interrupt range, but is treated almost like any other AFU interrupt when creating/deleting the context. Only the handler

[PATCH v4 06/18] cxl: Isolate a few bare-metal-specific calls

A few functions are mostly common between bare-metal and guest and just need minor tuning. To avoid crowding the backend API, introduce a few 'if' based on the CPU being in HV mode. Co-authored-by: Christophe Lombard Signed-off-by: Frederic Barrat

[PATCH v4 07/18] cxl: Update cxl_irq() prototype

The context parameter when calling cxl_irq() should be strongly typed. Co-authored-by: Christophe Lombard Signed-off-by: Frederic Barrat Signed-off-by: Christophe Lombard Acked-by: Ian Munsie

[PATCH v4 04/18] cxl: Introduce implementation-specific API

The backend API (in cxl.h) lists some low-level functions whose implementation is different on bare-metal and in a guest. Each environment implements its own functions, and the common code uses them through function pointers, defined in cxl_backend_ops Co-authored-by: Christophe Lombard

[PATCH v4 05/18] cxl: Rename some bare-metal specific functions

Rename a few functions, changing the 'cxl_' prefix to either 'cxl_pci_' or 'cxl_native_', to make clear that the implementation is bare-metal specific. Those functions will have an equivalent implementation for a guest in a later patch. Co-authored-by: Christophe Lombard

[PATCH v4 01/18] cxl: Move common code away from bare-metal-specific files

From: Christophe Lombard Move around some functions which will be accessed from the bare-metal and guest environments. Code in native.c and pci.c is meant to be bare-metal specific. Other files contain code which may be shared with guests. Co-authored-by: Frederic

[PATCH v4 03/18] cxl: Define process problem state area at attach time only

Cxl kernel API was defining the process problem state area during context initialization, making it possible to map the problem state area before attaching the context. This won't work on a powerVM guest. So force the logical behavior, like in userspace: attach first, then map the problem state

[PATCH v4 02/18] cxl: Move bare-metal specific code to specialized files

Move a few functions around to better separate code specific to bare-metal environment from code which will be commonly used between guest and bare-metal. Code specific to bare-metal is meant to be in native.c or pci.c only. It's basically anything which touches the capi p1 registers, some p2

[PATCH v4 00/18] cxl: Add support for powerVM guest​

This series adds support for a CAPI card in a powerVM guest. It requires firmware FW840 and an activation code for CAPI. Note that pHyp only claims support for cxlflash, and not generic support for FPGA CAPI accelerators. cxlflash uses the (slightly modified) Nallatech card, so the memcopy AFU

Re: [PATCH v5] powerpc32: provide VIRT_CPU_ACCOUNTING

On Thu, 2016-02-11 at 17:16 +0100, Christophe Leroy wrote: > This patch provides VIRT_CPU_ACCOUTING to PPC32 architecture. > PPC32 doesn't have the PACA structure, so we use the task_info > structure to store the accounting data. > > In order to reuse on PPC32 the PPC64 functions, all u64 data

[PATCH] add POWER Virtual Management Channel driver

From: Steven Royer The ibmvmc driver is a device driver for the POWER Virtual Management Channel virtual adapter on the PowerVM platform. It is used to communicate with the hypervisor for virtualization management. It provides both request/response and asynchronous message

Re: Writes, smp_wmb(), and transitivity?

On Tue, Feb 16, 2016 at 10:59:08AM -0800, Linus Torvalds wrote: > On Mon, Feb 15, 2016 at 9:58 AM, Paul E. McKenney > wrote: > > > > Two threads: > > > > int a, b; > > > > void thread0(void) > > { > > WRITE_ONCE(a, 1); > >

Re: Writes, smp_wmb(), and transitivity?

On Mon, Feb 15, 2016 at 9:58 AM, Paul E. McKenney wrote: > > Two threads: > > int a, b; > > void thread0(void) > { > WRITE_ONCE(a, 1); > smp_wmb(); > WRITE_ONCE(b, 2); > } > > void

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On 02/15/2016 10:35 PM, Kirill A. Shutemov wrote: > > Is there any chance that I'll be able to trigger the bug using QEMU? > Does anybody have an QEMU image I can use? qemu/TCG on s390 does neither provide SMP nor large pages (only QEMU/KVM does) so this will probably not help you here.

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

On Mon, 15 Feb 2016 23:35:26 +0200 "Kirill A. Shutemov" wrote: > On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote: > > On Mon, 15 Feb 2016 13:31:59 +0200 > > "Kirill A. Shutemov" wrote: > > > > > On Sat, Feb 13, 2016 at 12:58:31PM

  1   2   >