This patch adds support for FSP EPOW (Early Power Off Warning) and
DPO (Delayed Power Off) events for PowerNV platform. EPOW events are
generated by SPCN/FSP due to various critical system conditions that
need system shutdown. Few examples of these conditions are high
ambient temperature or system
This patch adds support for FSP EPOW (Early Power Off Warning) and
DPO (Delayed Power Off) events for PowerNV platform. EPOW events are
generated by SPCN/FSP due to various critical system conditions that
need system shutdown. Few examples of these conditions are high
ambient temperature or system
yOn Sat, 16 May 2015, Torsten Duwe wrote:
There's got to be a better solution than this.
Can you think of a better approach?
Maybe a per thread variable to lock out a recursion into tracing?
Thanks for your doubt.
ftrace already handles recursion protection by itself (depending on the
From: Igal Liberman igal.liber...@freescale.com
This patch adds a compatible which represents FMan V3 best effort ports.
FMan best effort port is configured as 10G ports, however, it uses 1G
hardware.
Signed-off-by: Igal Liberman igal.liber...@freescale.com
---
On Mon, May 18, 2015 at 12:32:29AM -0700, Haren Myneni wrote:
Mel,
I am hitting this issue with 4.0 kernel and even with 3.19 and
3.17 kernels. I will also try with previous versions. Please let me
know any suggestions on the debugging.
Please keep going further back in time to see if
On 5/18/15, Mel Gorman mgor...@suse.de wrote:
On Mon, May 18, 2015 at 12:32:29AM -0700, Haren Myneni wrote:
Mel,
I am hitting this issue with 4.0 kernel and even with 3.19 and
3.17 kernels. I will also try with previous versions. Please let me
know any suggestions on the debugging.
On Mon, 2015-05-18 at 11:41 +0300, Igal.Liberman wrote:
From: Igal Liberman igal.liber...@freescale.com
This patch adds a compatible which represents FMan V3 best effort ports.
FMan best effort port is configured as 10G ports, however, it uses 1G
hardware.
Signed-off-by: Igal Liberman
This patchset enables EEH on SRIOV VFs. The general idea is to create proper
VF edev and VF PE and handle them properly.
Different from the Bus PE, VF PE just contain one VF. This introduces the
difference of EEH error handling on a VF PE. Generally, it has several
differences.
First, the VF's
Different from PCI bus dependent PE, PE for VFs doesn't have the
primary bus, on which the PCI hotplug is implemented. The patch
supports error recovery, especially the PCI hotplug for VF's PE.
The hotplug on VF's PE is implemented based on VFs, instead of
PCI bus any more.
[gwshan: changelog and
When VF BAR size is larger than 64MB, we group VFs in terms of M64 BAR,
which means those VFs in a group should form a compound PE.
This patch links those VF PEs into compound PE in this case.
[gwshan: code refactoring for a bit]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin
Bjorn,
This patch set is dedicated for the VF EEH on Power. Most of them are in
powerpc arch, while this first one is PCI core related. Those following
patches are review and ack from Gavin, your ack to this one is important.
I'd appreciated it a lot if you have time to take a look at this one.
On Mon, 2015-05-18 at 14:29 +0200, Jiri Kosina wrote:
yOn Sat, 16 May 2015, Torsten Duwe wrote:
There's got to be a better solution than this.
Can you think of a better approach?
Maybe a per thread variable to lock out a recursion into tracing?
Thanks for your doubt.
ftrace
On Fri, 2015-05-15 at 14:06 +1000, Alistair Popple wrote:
Convert the opal hvc driver to use the new irqchip to register for
opal events. As older firmware versions may not have device tree
bindings for the interrupt parent we just use a hardcoded hwirq based
on the event number.
This is
On Tue, 19 May 2015 14:33:39 Michael Ellerman wrote:
On Fri, 2015-05-15 at 14:06 +1000, Alistair Popple wrote:
Convert the opal hvc driver to use the new irqchip to register for
opal events. As older firmware versions may not have device tree
bindings for the interrupt parent we just use a
During EEH recovery, hotplug is applied to the devices which don't
have drivers or their drivers don't support EEH. However, the hotplug,
which was implemented based on PCI bus, can't be applied to VF directly.
The patch renames virtn_{add,remove}() and exports them so that they
can be used in
The patch caches the VF index in pci_dn, which can be used to calculate
VF's bus, device and function number. Those information helps to locate
the VF's PCI device instance when doing hotplug during EEH recovery if
necessary.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Acked-by: Gavin Shan
After PE reset, OPAL API opal_pci_reinit() is called on all devices
contained in the PE to reinitialize them. However, VFs can't be seen
from skiboot firmware. We have to implement the functions, similar
those in skiboot firmware, to reinitialize VFs after reset on PE
for VFs.
[gwshan: changelog
PEs for VFs don't have primary bus. So they have to have their own reset
backend, which is used during EEH recovery. The patch implements the reset
backend for VF's PE by issuing FLR or AF FLR to the VFs, which are contained
in the PE.
[gwshan: changelog and code refactoring]
Signed-off-by: Wei
EEH address cache, which helps to locate the PCI device according to
the given (physical) MMIO address, didn't cover PCI bridges. Also, it
shouldn't return PF with address in PF's IOV BARs. Instead, the VFs
should be returned.
The patch restricts the address cache to cover first 7 BARs for the
Hi Linus,
Please pull some more powerpc fixes for 4.1:
The following changes since commit 030bbdbf4c833bc69f502eae58498bc5572db736:
Linux 4.1-rc3 (2015-05-10 15:12:29 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git
As commit ac205b7b (PCI: make sriov work with hotplug remove) indicates,
VFs, which might be hooked to same PCI bus as their PF should be removed
before the PF. Otherwise, the PCI hot unplugging on the PCI bus would
cause kernel crash.
The patch applies the above pattern to PowerPC PCI hotplug
Current EEH recovery code works with the assumption: the PE has primary
bus. Unfortunately, that's not true to VF PEs, which generally contains
one or multiple VFs (for VF group case). The patch creates PEs for VFs
at PCI final fixup time. Those PEs for VFs are indentified with newly
introduced
VFs and their corresponding pci_dn instances are created and released
dynamically as their PF's SRIOV capability is enabled and disabled.
The patch creates and releases EEH devices for VFs when creating and
releasing their pci_dn instances, which means EEH devices and pci_dn
instances have same
On Mon, 2015-18-05 at 03:56:51 UTC, Benjamin Herrenschmidt wrote:
This patch adds the ability to the DMA direct ops to fallback to the IOMMU
ops for coherent alloc/free if the coherent mask of the device isn't
suitable for accessing the direct DMA space and the device also happens
to have an
Hi Arnd,
On Wed, May 13, 2015 at 5:21 PM, Suman Tripathi stripa...@apm.com wrote:
This patch adds the arasan mmc nodes to reuse the of-arasan
driver for APM X-Gene SoC.
Signed-off-by: Suman Tripathi stripa...@apm.com
---
---
arch/arm64/boot/dts/apm/apm-mustang.dts | 4 +++
On Wed, May 13, 2015 at 5:21 PM, Suman Tripathi stripa...@apm.com wrote:
The sdhci framework disables SDR104/SDR50/DDR50 based on only quirk.
This patch adds the support to disable SDR104/SDR50/DDR50 based on
reading the capability register 0.
Signed-off-by: Suman Tripathi stripa...@apm.com
Mel,
I am hitting this issue with 4.0 kernel and even with 3.19 and
3.17 kernels. I will also try with previous versions. Please let me
know any suggestions on the debugging.
Thanks
Haren
On 5/14/15, Haren Myneni hmyn...@gmail.com wrote:
On 5/14/15, Mel Gorman mgor...@suse.de wrote:
On
At Sat, 9 May 2015 19:42:22 +0200,
Wolfram Sang wrote:
As we now have deferred probing, we can use a custom mechanism and
finally get rid of this legacy interface from the i2c core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
Tested-by: Dan DeVoto dand1...@yahoo.com
Tested-by: Mark
On 05/18/2015 10:39 AM, Anton Blanchard wrote:
Hi Anshuman,
Thanks for getting these testcases into the kernel.
This patch adds a test to verify that the changed DSCR value inside
any process would be inherited to it's child process across the fork
system call.
One issue I do notice (a
This patch adds .gitignore for all the newly added DSCR tests.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
tools/testing/selftests/powerpc/dscr/.gitignore | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 tools/testing/selftests/powerpc/dscr/.gitignore
diff
This patch adds some in-code documentation to the DSCR related
code to make it more readable without having any functional
change to it.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/processor.h | 9 +
arch/powerpc/kernel/sysfs.c | 38
This patch series has patches for POWER DSCR fixes, improvements,
in code documentaion, kernel support user documentation and selftest based
test cases. It has got five test cases which are derived from Anton's DSCR
test bucket which can be listed as follows.
(1)
This patch adds a test case to verify that the changed DSCR value
inside any process would be inherited to it's child across the fork
and exec system call.
Acked-by: Shuah Khan shua...@osg.samsung.com
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Signed-off-by: Anton Blanchard
This patch adds a test to verify that the changed DSCR value inside
any process would be inherited to it's child process across the fork
system call.
Acked-by: Shuah Khan shua...@osg.samsung.com
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Signed-off-by: Anton Blanchard
Currently DSCR (Data Stream Control Register) can be accessed with
mfspr or mtspr instructions inside a thread via two different SPR
numbers. One being the user accessible problem state SPR number 0x03
and the other being the privilege state SPR number 0x11. All access
through the privilege state
This patch adds a test which verifies that the DSCR privilege and
problem state SPR read write accesses while making sure that the
results are always the same irrespective of which SPR number is
being used.
Acked-by: Shuah Khan shua...@osg.samsung.com
Signed-off-by: Anshuman Khandual
PACA_DSCR offset macro tracks dscr_default element in the paca
structure. Better change the name of this macro to match that
of the data element it tracks. Makes the code more readable.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/kernel/asm-offsets.c | 2
This test continuously updates the system wide DSCR default value
in the sysfs interface and makes sure that the same is reflected
across all the sysfs interfaces for each individual CPUs present
on the system.
Acked-by: Shuah Khan shua...@osg.samsung.com
Signed-off-by: Anshuman Khandual
The process context switch code no longer uses dscr_default variable
from the sysfs.c file. The variable became unused when we started
storing the CPU specific DSCR value in the PACA structure instead.
This patch just removes this extern declaration. It was originally
added by the following
This patch adds a new documentation file explaining the DSCR
support on powerpc platforms. This explains DSCR related data
structure, code paths and also available user interfaces. Any
further functional changes to the DSCR support in the kernel
should definitely update the documentation here.
This patch adds a test which modifies the DSCR using mtspr instruction
and verifies the change using mfspr instruction. It uses both the
privilege state SPR as well as the problem state SPR for the purpose.
Acked-by: Shuah Khan shua...@osg.samsung.com
Signed-off-by: Anshuman Khandual
This patch adds a test to update the system wide DSCR value repeatedly
and then verifies that any thread on any given CPU on the system must
be able to see the same DSCR value whether its is being read through
the problem state based SPR or the privilege state based SPR.
Acked-by: Shuah Khan
This patch adds a test case for the system wide DSCR default
value, which when changed through it's sysfs interface must
be visible to all threads reading DSCR either through the
privilege state SPR or the problem state SPR. The DSCR value
change should be immediate as well.
Acked-by: Shuah Khan
43 matches
Mail list logo
