On 7/5/2011 1:34 PM, Richard A Lary wrote:
On 7/5/2011 10:22 AM, Richard A Lary wrote:
On 7/5/2011 9:18 AM, Jon Mason wrote:
On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
wrote:
On 7/1/2011 1:00 PM, Richard A Lary wrote:
On 7/1/2011 12:02 PM, Jon Mason wrote:
On Fri, Jul 1, 2011 at 1
On 7/5/2011 10:22 AM, Richard A Lary wrote:
On 7/5/2011 9:18 AM, Jon Mason wrote:
On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
wrote:
On 7/1/2011 1:00 PM, Richard A Lary wrote:
On 7/1/2011 12:02 PM, Jon Mason wrote:
On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary
wrote:
On 7/1/2011 8
On 7/5/2011 9:18 AM, Jon Mason wrote:
On Tue, Jul 5, 2011 at 10:41 AM, Richard A Lary
wrote:
On 7/1/2011 1:00 PM, Richard A Lary wrote:
On 7/1/2011 12:02 PM, Jon Mason wrote:
On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary
wrote:
On 7/1/2011 8:24 AM, Jon Mason wrote:
I recently sent
On 7/1/2011 1:00 PM, Richard A Lary wrote:
On 7/1/2011 12:02 PM, Jon Mason wrote:
On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote:
On 7/1/2011 8:24 AM, Jon Mason wrote:
I recently sent out a number of patches to migrate drivers calling
`pci_find_capability(pdef, PCI_CAP_ID_EXP)` to
On 7/1/2011 12:02 PM, Jon Mason wrote:
On Fri, Jul 1, 2011 at 1:30 PM, Richard A Lary wrote:
On 7/1/2011 8:24 AM, Jon Mason wrote:
I recently sent out a number of patches to migrate drivers calling
`pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
function takes uses a PCI-E
On 7/1/2011 8:24 AM, Jon Mason wrote:
I recently sent out a number of patches to migrate drivers calling
`pci_find_capability(pdef, PCI_CAP_ID_EXP)` to pci_pcie_cap. This
function takes uses a PCI-E capability offset that was determined by
calling pci_find_capability during the PCI bus walking.
From: Richard A Lary
For adapters which have devices under a PCIe switch/bridge it is informative
to display information for both the PCIe switch/bridge and the device on
which the bus error was detected.
rebased to powerpc-next
Signed-off-by: Richard A Lary
---
---
arch/powerpc
From: Richard A Lary
For adapters which have devices under a PCIe switch/bridge it is informative
to display information for both the PCIe switch/bridge and the device on
which the bus error was detected.
Signed-off-by: Richard A Lary
---
arch/powerpc/platforms/pseries/eeh_driver.c | 24
From: Richard A Lary
For adapters which have devices under a PCIe switch/bridge it is informative
to display information for both the PCIe switch/bridge and the device on
which the bus error was detected.
Signed-off-by: Richard A Lary
---
arch/powerpc/platforms/pseries/eeh_driver.c | 24
From: Richard A Lary
Fundamental reset is an optional reset type supported only by PCIe adapters.
Handle the unexpected case where a non-PCIe device has requested a
fundamental reset. Try hot-reset as a fallback to handle this case.
Signed-off-by: Richard A Lary
---
arch/powerpc/platforms
From: Richard A Lary
For multifunction adapters with a PCI bridge or switch as the device
at the Partitionable Endpoint(PE), if one or more devices below PE
sets dev->needs_freset, that value will be set for the PE device.
In other words, if any device below PE requires a fundamental re
This patch set contains three patches, all to eeh.c,
which fix a issue seen on PCIe adapters with devices below
PCIe bridge/switch, gracefully handle case where driver
sets 'needs_freset' for non-PCIe adapter, and display
location information for both PCIe bus and device for
the device which detec
On 4/6/2011 8:35 PM, Benjamin Herrenschmidt wrote:
On Wed, 2011-04-06 at 15:50 -0700, Richard A Lary wrote:
From: Richard A. Lary
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Care to tell us a bit about the difference ? :-) There's nothing obvious
in the
From: Richard A. Lary
Added support for ibm,configure-pe RTAS call introduced with
PAPR 2.2.
Signed-off-by: Richard A. Lary
---
arch/powerpc/platforms/pseries/eeh.c | 1312 +1 - 0 !
1 file changed, 12 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/platforms/pseries/eeh.c
14 matches
Mail list logo
