v2: Remove some reserved-memory properties
Split the patchset per IP block
Refined patch assignment
Kumar Gala (4):
powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA BMan
powerpc/mpc85xx: Create dts components for the FSL QorIQ DPAA QMan
powerpc/mpc85xx: Add
From: Kumar Gala ga...@kernel.crashing.org
Change-Id: I16e63db731e55a3d60d4e147573c1af8718082d3
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Hai-Ying Wang haiying.w...@freescale.com
[Emil Medve: Sync with the upstream
From: Kumar Gala ga...@kernel.crashing.org
Change-Id: I16e63db731e55a3d60d4e147573c1af8718082d3
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Hai-Ying Wang haiying.w...@freescale.com
[Emil Medve: Sync with the upstream
On Thu, Nov 20, 2014 at 07:52:08PM +0530, Neelesh Gupta wrote:
On 11/16/2014 10:47 PM, Neelesh Gupta wrote:
The patch exposes the available i2c busses on the PowerNV platform
to the kernel and implements the bus driver to support i2c and
smbus commands.
The driver uses the platform device
On 11/21/14, Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
On 11/14/2014 03:30 PM, Denis Kirjanov wrote:
On 11/13/14, Anshuman Khandual khand...@linux.vnet.ibm.com wrote:
On 11/11/2014 10:56 AM, Anshuman Khandual wrote:
This patch enables get and set of miscellaneous debug registers
On pseries system (LPAR) xmon failed to enter when running in LE mode, system
is hunging. Inititating xmon will lead to such an output on the console:
SysRq : Entering xmon
cpu 0x15: Vector: 0 at [c003f39ffb10]
pc: c007ed7c: sysrq_handle_xmon+0x5c/0x70
lr: c007ed7c:
On 11/21/2014 01:49 AM, Cyril Bur wrote:
On Mon, 2014-11-17 at 15:51 -0600, Nathan Fontenot wrote:
Create a new entry point for device hotplug on pseries that will
work for both PowerVM and PowerKVM systems.
The current process to hotplug (or dlpar) devices (generally the same
process for
On 11/21/2014 01:49 AM, Cyril Bur wrote:
On Mon, 2014-11-17 at 15:54 -0600, Nathan Fontenot wrote:
Move handling of memory hotplug add on pseries completely into the kernel.
The current memory hotplug add path involves the drmgr command doing part
of this work in userspace and requesting
On 11/21/2014 01:49 AM, Cyril Bur wrote:
On Mon, 2014-11-17 at 15:56 -0600, Nathan Fontenot wrote:
Move handling of memory hotplug remove on pseries completely into the kernel.
The current memory hotplug remove path involves the drmgr command doing part
of this work in userspace and
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Cleanup OpalMCE_* definitions/declarations and other related code which
is not used anymore.
Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 104 -
On Mon, 2014-11-24 at 09:03 -0600, Nathan Fontenot wrote:
On 11/21/2014 01:49 AM, Cyril Bur wrote:
On Mon, 2014-11-17 at 15:56 -0600, Nathan Fontenot wrote:
Move handling of memory hotplug remove on pseries completely into the
kernel.
The current memory hotplug remove path
Obviously I had wrong format given to the PE state output from
/sys/bus/pci/devices//eeh_pe_state with some typoes, which
was introduced by commit 2013add4 (powerpc/eeh: Show hex prefix
for PE state sysfs). The patch fixes it up.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE,
which is translated to OPAL_DEASSERT_RESET or something else by the
EEH backend accordingly.
The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for
ioda_eeh_phb_reset().
Signed-off-by: Gavin Shan
PE#0 should be regarded as valid for P7IOC, while it's invalid for
PHB3. The patch adds flag EEH_VALID_PE_ZERO to differentiate those
two cases. Without the patch, we possibly see frozen PE#0 state is
cleared without EEH recovery taken on P7IOC as following kernel logs
indicate:
[root@ltcfbl8eb
The OF_RECONFIG notifier callback uses a different structure depending
on whether it is a node change or a property change. This is silly, and
not very safe. Rework the code to use the same data structure regardless
of the type of notifier.
Signed-off-by: Grant Likely grant.lik...@linaro.org
Cc:
The patch refactors ioda_eeh_reset() to avoid unnecessary nested
if statements, so that the code looks simplified to earn a bit
more readibility, no logic changed.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 58
For PHB complete reset case, EEH_RESET_DEACTIVATE followed by
EEH_RESET_{HOT,FUNDAMENTAL} requests are issued by EEH core.
All of them are translated to raising complete reset wrongly
and we did complete reset for twice unnecessarily for each
transaction.
The patch fixes above issue by
With unified PCI slot reset infrastructure supported by the firmware,
we needn't reinitialize the affected devices after PE reset. OPAL API
opal_pci_reinit() and related logic, including EEH restore_config()
callback can be killed safely. All the work covered by opal_pci_reinit()
should be done in
The patchset corresponds to skiboot changes, which manages PCI slots
in a unified way: OPAL APIs used to do slot reset, power management,
presence status retrival. The patchset shouldn't be merged before
the OPAL firmware counterpart is merged.
The kernel changes have been split into 2 parts: (A)
The patch reworks the reset logic to reuse PCI slot reset
infrastructure implemented in OPAL firmware. For one particular
PCI slot, we have switch to hot reset in case the firmware can't
support reset for it.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/eeh.h
pnv_pci_reset_secondary_bus() is the backend for resetting the
secondary bus for the specified PCI bridge. We always issue hot
reset, which isn't enough for some devices who requires fundamental
reset explicitly. The patch switches to fundamental reset if the
devices ask for that.
Signed-off-by:
The direct or indirect parent of hotpluggable slot has possibility
to be hotpluggable. Unfortunately, current implementation doesn't
cover it. The patch fixes the issue:
* When adding slots based on the given device node, the child
device nodes are scanned to see if they're hotpluggable
The patch moves pcibios_find_pci_bus() to PPC kerenl directory so
that it can be reused by hotplug code for pSeries and PowerNV
platform at the same time.
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/kernel/pci-hotplug.c | 36 ++
In hotplug case, function pcibios_add_pci_devices() is called to
rescan the specified PCI bus, which possibly doesn't have any child
devices. Access to the PCI bus's child device node will cause kernel
crash without exception. The patch adds two more conditions to avoid
the kernel crash.
The patch exports two functions, which base on corresponding OPAL
APIs to retrieve PCI slot status:
pnv_pci_get_power_status() opal_pci_get_power_status()
pnv_pci_get_presence_status() opal_pci_get_presence_status()
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
The patch applies code cleanup to RPA modules to address following
issues and it shouldn't affect the logic:
* Coding style issue: removed unnecessary break for default case
in switch statement and added default case; removed unnecessary
braces or parenthese for if or return
The series of patches depends on the OPAL firmware changes. Please
don't consider merging it before the OPAL firmware changes get merged!
The series of patches intends to support PCI slots for OPAL firmware
based PPC PowerNV platform. The OPAL firmware exports the capabilities
to check various
The patch splits the code into 2 parts: RPA PCI hotplug slot
management and RTAS backend. It enables us to support PowerNV,
which is built on top of OPAL firmware in future.
The patch also refactors the code for a bit:
* Rename struct slot to struct rpa_php_slot
* All macros have prefix
When loading rpaphp.ko on a P7 box, I didn't see any PCI slots
created under /sys/bus/pci/slots as expected. It seems that the
RPA PCI slot stuff has been broken for long time. The driver
doesn't use the properties of PCI device-tree nodes properly to
populate PCI slots: device-tree node property
On Mon, 2014-11-24 at 05:07 -0600, Emil Medve wrote:
From: Kumar Gala ga...@kernel.crashing.org
Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Hai-Ying Wang
On Mon, 2014-11-24 at 21:59 +0530, Mahesh J Salgaonkar wrote:
From: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Cleanup OpalMCE_* definitions/declarations and other related code which
is not used anymore.
Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Acked-by: Benjamin
On Mon, 2014-11-24 at 13:18 +0100, Wolfram Sang wrote:
I think there are now 3 drivers in my queue which are not fully I2C
compatible but more supporting the very minimum to, say, read an
eeprom.
I am not feeling well to allow them to use I2C_FUNC_I2C. So, I want to
think about ways how to
On 11/22/2014 05:13 AM, Andrew Morton wrote:
On Tue, 11 Nov 2014 10:56:30 +0530 Anshuman Khandual
khand...@linux.vnet.ibm.com wrote:
This patch adds four new core note sections for PowerPC transactional
memory and one core note section for general miscellaneous debug registers.
These
33 matches
Mail list logo
