On Thu, 2014-04-24 at 13:46 -0500, Scott Wood wrote:
> On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, April 17, 2014 3:36 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Jin Zhengxiong-R64188; ha
On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Thursday, April 17, 2014 3:36 AM
> > To: Wang Dongsheng-B40534
> > Cc: Jin Zhengxiong-R64188; haoke...@gmail.com; Kushwaha Prabhakar-B32579;
> > linuxppc-dev@lists
On 24 April 2014 12:57, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:17, Russell King - ARM Linux
>> wrote:
>> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> >> I have looked though the patches up until p
On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >> a nice piece of clean-up /fixe
On 24 April 2014 12:17, Russell King - ARM Linux wrote:
> On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> I have looked though the patches up until patch 33 and this is clearly
>> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> comments per patch, I don't have a
On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
>
>
On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > compatible string? From grepping through the kernel I could only find a
> > model string ("IBM,LongTrail").
>
> Actually, on LongTrail this can be removed f
On 23 April 2014 20:55, Russell King - ARM Linux wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appear
PCI accessors from user space pci_user_{read,write}_config_*()
return negative error number, which was introduced by commit
34e32072 ("PCI: handle positive error codes"). That patch coverts
all positive error numbers from platform specific PCI config
accessors to -EINVAL. The upper layer calling to
If the PE contains single PCI function, "pe->pbus" would be NULL.
It's not reliable to be used by pci_domain_nr(). We just grab the
PCI domain number from the PCI host controller (struct pci_controller)
instance.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 ++--
Function early_init_dt_scan_fw_dump() is called to scan the device
tree for fdump properties under node "rtas". Any one of them is
invalid, we can stop scanning the device tree early by returning
"1". It would save a bit time during boot.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/fadump.
In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is
set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally.
It was just set to TCE_PCI by pnv_pci_setup_iommu_table(). So the
primary IOMMU table type (TCE_PCI) is lost. The patch fixes it.
Also, pnv_pci_setup_iommu_table()
Resetting root port has more stuff to do than that for PCIe switch
ports and we should have resetting root port done in firmware instead
of the kernel itself. The problem was introduced by commit 5b2e198e
("powerpc/powernv: Rework EEH reset").
Cc: linux-stable
Signed-off-by: Gavin Shan
---
arch
When PCI_ERS_RESULT_CAN_RECOVER returned from device drivers, the
EEH core should enable I/O and DMA for the affected PE. However,
it was missed to have DMA enabled in eeh_handle_normal_event().
Besides, the frozen state of the affected PE should be cleared
after successful recovery, but we didn't.
Basically, we have 3 types of resets to fulfil PE reset: fundamental,
hot and PHB reset. For the later 2 cases, we need PCI bus reset hold
and settlement delay as specified by PCI spec. PowerNV and pSeries
platforms are running on top of different firmware and some of the
delays have been covered b
In the kdump scenario, the first kerenl doesn't shutdown PCI devices
and the kdump kerenl clean PHB IODA table at the early probe time.
That means the kdump kerenl can't support PCI transactions piled
by the first kerenl. Otherwise, lots of EEH errors and frozen PEs
will be detected.
In order to a
The patch intends to support fundamental reset on PLX downstream
ports. If the PCI device matches any one of the internal table,
which includes PLX vendor ID, bridge device ID, register offset
for fundamental reset and bit, fundamental reset will be done
accordingly. Otherwise, it will fail back to
The problem was initially reported by Wendy who tried pass through
IPR adapter, which was connected to PHB root port directly, to KVM
based guest. When doing that, pci_reset_bridge_secondary_bus() was
called by VFIO driver and linkDown was detected by the root port.
That caused all PEs to be frozen
The patch introduces bootarg "eeh=off" to disable EEH functinality.
Also, it creates /sys/kerenl/debug/powerpc/eeh_enable to disable
or enable EEH functionality. By default, we have the functionality
enabled.
For PowerNV platform, we will restore to have the conventional
mechanism of clearing froz
There're 2 EEH subsystem variables: eeh_subsystem_enabled and
eeh_probe_mode. We needn't maintain 2 variables and we can just
have one variable and introduce different flags. The patch also
introduces additional flag EEH_FORCE_DISABLE, which will be used
to disable EEH subsystem via boot parameter
Once one specific PE has been marked as EEH_PE_ISOLATED, it's in
the middile of recovery or removed permenently. We needn't report
the frozen PE again. Otherwise, we will have endless reporting
same frozen PE.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 7 +++
1
In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.
Reported-by: Joe Perches
Cc: linux-stable
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 1 +
1 file ch
The issue was detected in a bit complicated test case where
we have multiple hierarchical PEs shown as following figure:
+-+
| PE#3 p2p#0 |
| p2p#1 |
+-+
|
We have suffered recrusive frozen PE a lot, which was caused
by IO accesses during the PE reset. Ben came up with the good
idea to keep frozen PE until recovery (BAR restore) gets done.
With that, IO accesses during PE reset are dropped by hardware
and wouldn't incur the recrusive frozen PE any mor
We've observed multiple PE reset failures because of PCI-CFG
access during that period. Potentially, some device drivers
can't support EEH very well and they can't put the device to
motionless state before PE reset. So those device drivers might
produce PCI-CFG accesses during PE reset. Also, we co
When calling into eeh_gather_pci_data() on pSeries platform, we
possiblly don't have pci_dev instance yet, but eeh_dev is always
ready. So we use cached capability from eeh_dev instead of pci_dev
for log dump there. In order to keep things unified, we also cache
PCI capability positions to eeh_dev
When doing PE reset, EEH_PE_ISOLATED is cleared unconditionally.
However, We should remove that if the PE reset has cleared the
frozen state successfully. Otherwise, the flag should be kept.
The patch fixes the issue.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 10 +++---
1 fil
The PHB state PNV_EEH_STATE_REMOVED maintained in pnv_phb isn't
so useful any more and it's duplicated to EEH_PE_ISOLATED. The
patch replaces PNV_EEH_STATE_REMOVED with EEH_PE_ISOLATED.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 56 +--
For EEH PowerNV backends, they need use their own PCI config
accesors as the normal one could be blocked during PE reset.
The patch also removes necessary parameter "hose" for the
function ioda_eeh_bridge_reset().
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 23 +
The patch replaces printk(KERN_WARNING ...) with pr_warn() in the
function eeh_gather_pci_data().
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/eeh.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/ker
For some fields (e.g. LEM, MMIO, DMA) in PHB diag-data dump, it's
meaningless to print them if they have non-zero value in the
corresponding mask registers because we always have non-zero values
in the mask registers. The patch only prints those fieds if we
have non-zero values in the primary regis
The series of patches enhances EEH to block I/O and PCI-CFG access during
PE reset. Besides, it includes various bug fixes regarding EEH.
Gavin Shan (25):
powerpc/eeh: Remove EEH_PE_PHB_DEAD
powerpc/powernv: Remove PNV_EEH_STATE_REMOVED
powerpc/powernv: Move PNV_EEH_STATE_ENABLED around
po
The PE state (for eeh_pe instance) EEH_PE_PHB_DEAD is duplicate to
EEH_PE_ISOLATED. Originally, those PHBs (PHB PE) with EEH_PE_PHB_DEAD
would be removed from the system. However, it's safe to replace
that with EEH_PE_ISOLATED.
The patch also clear EEH_PE_RECOVERING after fenced PHB has been handl
The flag PNV_EEH_STATE_ENABLED is put into pnv_phb::eeh_state,
which is protected by CONFIG_EEH. We needn't that. Instead, we
can have pnv_phb::flags and maintain all flags there, which is
the purpose of the patch. The patch also renames PNV_EEH_STATE_ENABLED
to PNV_PHB_FLAG_EEH.
Signed-off-by: Ga
The size of the sysparam sysfs files is determined from the device tree
at boot. However the buffer is hard coded to 64 bytes. If we encounter a
parameter that is larger than 64, or miss-parse the device tree, the
buffer will overflow when reading or writing to the parameter.
Check it at discovery
---
arch/powerpc/platforms/powernv/opal-sysparam.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/opal-sysparam.c
b/arch/powerpc/platforms/powernv/opal-sysparam.c
index 21fdc0a..4b3367b 100644
--- a/arch/powerpc/platforms/powernv/opal-syspar
The sysparam code currently uses the userspace supplied number of
bytes when memcpy()ing in to a local 64-byte buffer.
Limit the maximum number of bytes by the size of the buffer.
---
arch/powerpc/platforms/powernv/opal-sysparam.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/power
The OPAL calls are returning int64_t values, which the sysparam code
stores in an int, and the sysfs callback returns ssize_t. Make code a
easier to read by consistently using ssize_t.
Signed-off-by: Joel Stanley
---
arch/powerpc/platforms/powernv/opal-sysparam.c | 11 ++-
1 file changed
When a sysparam query in OPAL returned a negative value (error code),
sysfs would spew out a decent chunk of memory; almost 64K more than
expected. This was traced to a sign/unsigned mix up in the OPAL sysparam
sysfs code at sys_param_show.
The return value of sys_param_show is a ssize_t, calculat
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/elf_util.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/elf_util.c b/arch/powerpc/boot/elf_util.c
index 1567a0c0f05c..316552dea4d8 100644
--- a/arch/powerpc/boot/elf_util.c
+++ b/arch/powerpc/boot/elf_util.c
@@
These fix the issues I saw when testing the sysparam sysfs API. As some of the
parameters are not available on the machine I was using, the error paths in the
sysfs and OPAL code are tested, and were found to have some bugs.
Joel Stanley (5):
powerpc/powernv: Fix sysparam sysfs error handling
The code is only slightly modified : entry points now use the
FIXUP_ENDIAN trampoline to switch endian order. The 32bit wrapper
is kept for big endian kernels and 64bit is enforced for little
endian kernels with a PPC64_BOOT_WRAPPER config option.
The linker script is generated using the kernel pr
When entering the boot wrapper in little endian, we will need to fix
the endian order using a fixup trampoline like in the kernel. This
patch overrides the _zimage_start entry point for this purpose.
Signed-off-by: Cédric Le Goater
---
Changes since v1:
- pseries is not the only platform gener
This patch adds support a 64bit wrapper entry point. As in 32bit, the
entry point does its own relocation and can be loaded at any address
by the firmware.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/crt0.S | 108 --
1 file changed, 104 inse
This patch defines a 'prom' routine similar to 'enter_prom' in the
kernel.
The difference is in the MSR which is built before entering prom. Big
endian order is enforced as in the kernel but 32bit mode is not. It
prepares ground for the next patches which will introduce Little endian
order.
Signe
It could certainly be improved using Elf macros and byteswapping
routines, but the initial version of the code is organised to be a
single file program with limited dependencies. yaboot is the same.
Please scream if you want a total rewrite.
Signed-off-by: Cédric Le Goater
---
Changes since RFC
arch/powerpc/boot/oflib.c:211:9: warning: cast to pointer from integer of \
different size [-Wint-to-pointer-cast]
return (phandle) of_call_prom("finddevice", 1, 1, name);
This is a work around. The definite solution would be to define the
phandle typedef as a u32, as in the k
These are not the most efficient versions of swab but the wrapper does
not do much byte swapping. On a big endian cpu, these routines are
a no-op.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h |7 +++
arch/powerpc/boot/swab.h | 29 +
2 files c
This patch fixes 64bit compile warnings and updates the wrapper code
to converge the kernel code in prom_init.
Signed-off-by: Cédric Le Goater
---
Changes since v1:
- use PROM_ERROR to test return addr
arch/powerpc/boot/of.c|4 ++--
arch/powerpc/boot/of.h|3 ++-
arch/powerpc/
This makes ihandle 64bit friendly.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h|2 +-
arch/powerpc/boot/oflib.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
index 504a0a31b685..e1ef620082f7
This is mostly useful to make to the boot wrapper code closer with
the kernel code in prom_init.
Signed-off-by: Cédric Le Goater
---
Changes since v1:
- moved PROM_ERROR definition in of.h. of_try_claim() will make
use of it in the next patch.
arch/powerpc/boot/of.h|2 ++
arch/po
Values will need to be byte-swapped when calling prom (big endian) from
a little endian boot wrapper.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/of.h|3 +++
arch/powerpc/boot/ofconsole.c |6 --
arch/powerpc/boot/oflib.c | 22 +++---
3 files ch
This patch fixes warnings when the wrapper is compiled in 64bit and
updates the boot wrapper code related to prom to converge with the
kernel code in prom_init. This should make the review of changes easier.
The kernel has a different number of possible arguments (10) when
entering prom. There doe
This patch updates the wrapper code to converge with the kernel code in
prom_init.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/oflib.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/oflib.c b/arch/powerpc/boot/oflib.c
index c3288a3446
When the boot wrapper is compiled in 64bit, there is no need to
use __div64_32.
Signed-off-by: Cédric Le Goater
---
arch/powerpc/boot/stdio.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/powerpc/boot/stdio.c b/arch/powerpc/boot/stdio.c
index 5b57800bbc67..a701261b17
Hi,
The following patchset adds support for 64bit little endian boot
wrapper. It is based on original code from Andrew Tauferner.
The first patches provide fixes for 64bit support. I also changed
the prom code to make it converge with the prom_init kernel code.
They have a lot in common and t
56 matches
Mail list logo
