Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
Presently we only support initiating Service Processor dump from host.
Hence update sysfs message. Also update couple of other error/info
messages.
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
PowerNV platform is capable of capturing host memory region when system
crashes (because of host/firmware). We have new OPAL API to register
memory region to be capture when system crashes.
This patch adds support for new API and also
can do, along with the
OPAL/skiboot side fixes that I've mentioned separately.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
was before... so,
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
(not actually compiled or tested or anything, but my internal C
preprocesser says it looks okay :)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
Michael Ellerman m...@ellerman.id.au writes:
+OpalEjtIoaDmaWriteMemTarget = 19,
+};
I realise these come from the skiboot source, but they're just too ugly.
Please use kernel style naming, like most of the rest of the file, eg:
OPAL_ERR_INJECT_IOA_BUS_ERR
You know what, I
...@neuling.org
(checked the firmware code)
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
(although should we be checking if the call returns OPAL_PARAMETER?
The opal call will return that if booting on firmware without
OPAL_CHECK_TOKEN.. which granted, is pretty old firmware that I don't
*think* we
#if 0 out in skiboot?
for this patch:
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
+Each dump has the following files:
+id: An ASCII representation of the dump ID
+in hex (e.g. '0x01')
+type: An ASCII representation of the type of
+
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
index 000..32fe7f5
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-firmware-opal-dump
@@ -0,0 +1,41 @@
+What: /sys/firmware/opal/dump
+Date: Feb 2014
+Contact:Stewart Smith stew...@linux.vnet.ibm.com
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
+int64_t opal_send_ack_elog(uint64_t log_id);
Stewart,
Why are you creating 64bit log ID when actual ID is 32bit ?
IIRC it's what OPAL gives us, even though FSP MBOX spec says 32bit.
___
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Wed, 2014-03-05 at 08:56 +0530, Vasant Hegde wrote:
On 03/05/2014 07:26 AM, Stewart Smith wrote:
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
+int64_t opal_send_ack_elog(uint64_t log_id);
Stewart,
Why are you creating
Neelesh Gupta neele...@linux.vnet.ibm.com writes:
diff --git a/arch/powerpc/platforms/powernv/opal-async.c
b/arch/powerpc/platforms/powernv/opal-async.c
new file mode 100644
index 000..cd0c135
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-async.c
@@ -0,0 +1,203 @@
+/*
+ *
Anton Blanchard an...@samba.org writes:
Using size_t in our APIs is asking for trouble, especially
when some OPAL calls use size_t pointers.
Signed-off-by: Anton Blanchard an...@samba.org
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
---
Index: b/arch/powerpc/include/asm/opal.h
Anton Blanchard an...@samba.org writes:
Fix little endian issues with the OPAL error log code.
Signed-off-by: Anton Blanchard an...@samba.org
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
Do we also need any magic for the getting of error logs themselves?
You may want to check
Joel Stanley j...@jms.id.au writes:
OPAL provides an in-memory circular buffer containing a message log
populated with various runtime messages produced by the firmware.
Provide a sysfs interface /sys/firmware/opal/messages for userspace to
view the messages.
Acked-by: Stewart Smith stew
Greg Kurz gk...@linux.vnet.ibm.com writes:
struct rtas_error_log {
+#ifdef __BIG_ENDIAN__
+ /* Byte 0 */
unsigned long version:8;/* Architectural version */
+ /* Byte 1 */
I think it would be great if we got rid of the usage of bitfields. As
soon as the mood of
Greg Kurz gk...@linux.vnet.ibm.com writes:
On Mon, 31 Mar 2014 09:27:16 +1100
Stewart Smith stew...@linux.vnet.ibm.com wrote:
Greg Kurz gk...@linux.vnet.ibm.com writes:
struct rtas_error_log {
+#ifdef __BIG_ENDIAN__
+ /* Byte 0 */
unsigned long version:8
Benjamin Herrenschmidt b...@kernel.crashing.org writes:
On Mon, 2014-03-31 at 09:27 +1100, Stewart Smith wrote:
Greg Kurz gk...@linux.vnet.ibm.com writes:
struct rtas_error_log {
+#ifdef __BIG_ENDIAN__
+ /* Byte 0 */
unsigned long version:8;/* Architectural version
...@linux.vnet.ibm.com
Signed-off-by: Greg Kurz gk...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
A merge fix for powernv opal-dump and opal-elog code with driver-next
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-dump.c |9 ++---
arch/powerpc/platforms/powernv/opal-elog.c |9 ++---
2 files changed, 4 insertions(+), 14
Gavin Shan gws...@linux.vnet.ibm.com writes:
On Mon, Jun 23, 2014 at 04:36:44PM +1000, Michael Neuling wrote:
On Mon, 2014-06-23 at 12:14 +1000, Gavin Shan wrote:
The patch implements one OPAL firmware sysfs file to support PCI error
injection: /sys/firmware/opal/errinjct, which will be used
Gavin Shan gws...@linux.vnet.ibm.com writes:
+static struct kobj_attribute errinjct_attr =
+ __ATTR(errinjct, 0600, NULL, errinjct_store);
May also be good to have a read method that either lists current
injected errors? I guess it depends on if they're one time errors or
persistent errors
of STREAM benchmark results with this patch.
Based on preliminary investigation and microbenchmarks
by Prerna Saxena pre...@linux.vnet.ibm.com
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/kvm_host.h |1 +
arch/powerpc/include/asm/ppc-opcode.h | 10
of STREAM benchmark results with this patch.
Based on preliminary investigation and microbenchmarks
by Prerna Saxena pre...@linux.vnet.ibm.com
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
--
changes since v1:
- s/mppe/mpp_buffer/
- add MPP_BUFFER_ORDER define.
---
arch/powerpc/include
Hi!
Thanks for review, much appreciated!
Alexander Graf ag...@suse.de writes:
On 08.07.14 07:06, Stewart Smith wrote:
@@ -1528,6 +1535,7 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
int i, need_vpa_update;
int srcu_idx;
struct kvm_vcpu *vcpus_to_update
of STREAM benchmark results with this patch.
Based on preliminary investigation and microbenchmarks
by Prerna Saxena pre...@linux.vnet.ibm.com
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
--
changes since v2:
- based on feedback from Alexander Graf:
- move save and restore of cache
Paul Mackerras pau...@samba.org writes:
On Thu, Jul 17, 2014 at 01:19:57PM +1000, Stewart Smith wrote:
The POWER8 processor has a Micro Partition Prefetch Engine, which is
a fancy way of saying has way to store and load contents of L2 or
L2+MRU way of L3 cache. We initiate the storing
Alexander Graf ag...@suse.de writes:
diff --git a/arch/powerpc/include/asm/kvm_host.h
b/arch/powerpc/include/asm/kvm_host.h
index 1eaea2d..5769497 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -305,6 +305,8 @@ struct kvmppc_vcore {
u32
changes since v3:
- use kvmppc namespace
- MPP_BUFFER_ORDER of 3 not 4, as we only need 32k and it's already 32k aligned
- split out kvmppc_vcore_create in separate patch
- give a variable a better name: s/tmp/mpp_addr/
- logmpp becomes static inline function
Stewart Smith (2):
Split out struct
of STREAM benchmark results with this patch.
Based on preliminary investigation and microbenchmarks
by Prerna Saxena pre...@linux.vnet.ibm.com
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
--
changes since v3:
- use kvmppc namespace
- MPP_BUFFER_ORDER of 3 not 4, as we only need 32k
No code changes, just split it out to a function so that with the addition
of micro partition prefetch buffer allocation (in subsequent patch) looks
neater and doesn't require excessive indentation.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/kvm/book3s_hv.c | 31
Mahesh J Salgaonkar mah...@linux.vnet.ibm.com writes:
This patch adds support to read error logs from OPAL and export them
to userspace through sysfs interface /sys/firmware/opa/opal-elog.
I think we could provide a better interface with instead having a file
per log message appear in
not retrieve the dump, leaving us with a dump in linux that was
the correct size but all zeros.
Changes since v1: fixed typo
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/platforms/powernv/opal-dump.c |8
1
Michael Neuling mi...@neuling.org writes:
Stewart Smith stew...@linux.vnet.ibm.com wrote:
This fixes a bug where we would get two events from OPAL with DUMP_AVAIL
set (which is valid for OPAL to do) and in the second run of extract_dump()
we would fail to free the memory previously allocated
when OPAL
starts notifying us of all the dumps present.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
Documentation/ABI/stable/sysfs-firmware-opal-dump | 29 ++
arch/powerpc/include/asm/opal.h | 12 +
arch/powerpc/platforms/powernv/Makefile |2
Mahesh Jagannath Salgaonkar mah...@linux.vnet.ibm.com writes:
I think we could provide a better interface with instead having a file
per log message appear in sysfs. We're never going to have more than 128
of these at any one time on the Linux side, so it's not going to bee too
many files.
-by: Stewart Smith stew...@linux.vnet.ibm.com
---
Documentation/ABI/stable/sysfs-firmware-opal-dump | 41 ++
arch/powerpc/include/asm/opal.h | 14 +
arch/powerpc/platforms/powernv/Makefile |2 +-
arch/powerpc/platforms/powernv/opal-dump.c| 530
and am rather confident that the
linux side of things works rather well. There is currently an issue with
the service processor side of things for 128 error logs though.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
Documentation/ABI/stable/sysfs-firmware-opal-elog | 60
arch
support for getting dump type from OPAL through new OPAL call
(falling back to old OPAL_DUMP_INFO call if OPAL_DUMP_INFO2 isn't
supported)
- use dump type in directory name for dump
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
Documentation/ABI/stable/sysfs-firmware-opal
Pranith Kumar bobby.pr...@gmail.com writes:
On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman m...@ellerman.id.au
wrote:
On Wed, 2015-01-21 at 21:26 -0500, Pranith Kumar wrote:
When CONFIG_PRINTK=n, log_buf_addr_get() returns NULL and log_buf_len_get()
return 0. Check for these return
about
being unable to grab kernel log on crash every time you boot.
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/opal.c
b/arch/powerpc/platforms/powernv
Otherwise firmware complains: OPAL: Called with bad token 74 !
as not all OPAL systems have the ability to resend error logs.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-elog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Not all OPAL platforms support resending system dumps, so check
that current firmware supports it first. Otherwise we get firmware
complaining:
OPAL: Called with bad token 91 !
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
1
of these three warnings, it was OPAL_CHECK_TOKEN.
Stewart Smith (3):
powerpc/powernv: only register log if OPAL supports doing so
powerpc/powernv: only call OPAL_ELOG_RESEND if firmware supports it
powerpc/powernv: only call OPAL_RESEND_DUMP if firmware supports it
arch/powerpc/platforms/powernv
Correct use of REGISTER/UNREGISTER is to check if the token exists
before calling. If we don't we get a OPAL: Called with bad token 101 !
error, which is harmless but may be alarming to some.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal.c |6
-by: Michael Ellerman m...@ellerman.id.au
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
to document the API for some important
reason, 3) they are not used and needn't be part of the API.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Agree. The diff is now a TODO list for patches.
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
OPAL_PCI_SET_PHB_CAPI_MODE.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Reviewed-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Gavin Shan gws...@linux.vnet.ibm.com writes:
The patchset was built based on patchset powerpc/powernv: Simplify EEH
implementation, which can be found from:
https://patchwork.ozlabs.org/patch/439956/
The patchset corresponds to skiboot changes, which manages PCI slots
in a unified way:
.
(I find the hardcoding of snooze in the driver a bit odd, as is the
hardcoding of max power states to 8 - which could bite us in the future
if a future processor has more states... but these aren't problems with
this patch)
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Preeti U Murthy pre...@linux.vnet.ibm.com writes:
On 01/28/2015 02:45 PM, Stewart Smith wrote:
Preeti U Murthy pre...@linux.vnet.ibm.com writes:
The device tree now exposes the residency values for different idle states.
Read
these values instead of calculating residency from the latency
...@linux.vnet.ibm.com
Same acked-by as before, from perspective of I merged the firmware side
of things and things look godo in relation to firmware PoV.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
For whatever reason these structures were in different places.
Now they are not.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 48 +++
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/arch
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 9ca5167..7075f57 100644
--- a/arch/powerpc
.
In the process of doing this, I fixed a few things in firmware too,
so this matches skiboot at 4681ed9, which is a little after the most
recent skiboot release (4.1.1).
The biggest change is moving the function prototypes for API calls
out to opal-api.h.
Stewart Smith (18):
powerpc/powernv: sync OPAL
This patch just matches whitespace and comments between
the opal.h from firmware and that in linux.
No addition/removal.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal-api.h |4
arch/powerpc/include/asm/opal.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/opal-api.h
b/arch/powerpc/include/asm/opal-api.h
reduces the diff between linux and firmware header files significantly.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include
OPAL/IBM calls it CAPI and Linux calls it CXL because CAPI was taken.
In order to have opal.h match between firmware and Linux, we're going
to just deal with one call used in a place be CAPI rather than CXL to
match what's in firmware.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c09cf66..2aaa861 100644
--- a/arch
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 4373010..240ee1c 100644
--- a/arch/powerpc/include/asm
To further the cause of syncing opal.h between firmware and linux,
move the function prototypes that were in opal.h out to opal-api.h
and fix the associated includes.
There are still a few places where opal.h is adequate.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2aaa861..b60a25a 100644
--- a/arch/powerpc/include/asm
Some enums in firmware opal.h were missing from linux opal.h, add them.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 2441f36..68ce7ef 100644
--- a/arch/powerpc/include/asm
This finally syncs the content of opal.h between linux and firmware
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 7075f57..31b9656 100644
--- a/arch/powerpc/include/asm
This just leaves us with CXL vs CAPI as differences in the list of OPAL
calls between opal.h in firmware and opal.h in Linux.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git
Adds OPAL_MSG_DPO and docs for OPAL_MSG_SHUTDOWN
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 3786c6b
For whatever strange reason, these two structures were in different
locations in opal.h in firmware and opal.h in Linux. Move them around
to match firmware so that the diff is less.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 32
this adds CAPI and EPOW parts to opal.h that previously were only
in firmware opal.h
Currently unused, but gets us really close to being able to share
opal.h between firmware and linux.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/opal.h | 52
Vipin K Parashar vi...@linux.vnet.ibm.com writes:
(1) Environmental and Power Warning (EPOW)
(2) Delayed Power Off (DPO)
The user interface for this driver is /dev/opal_event character
device file where the user space clients can poll and read for
new opal platform events. The
Stanley j...@jms.id.au
I merged the firmware side of things, this looks like it implements what
firmware exports.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
Vipin K Parashar vi...@linux.vnet.ibm.com writes:
- What do UPSs do? It would seem that some common this is what's about
to happen to your power would almost *have* to exist somewhat
generically?
UPS class tells about UPS status with system. FSP sends mbox messages
with UPS status
Correct use of REGISTER/UNREGISTER is to check if the token exists
before calling. If we don't we get a OPAL: Called with bad token 101 !
error, which is harmless but may be alarming to some.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal.c |6
.
Stewart Smith (3):
powerpc/powernv: only register log if OPAL supports doing so
powerpc/powernv: only call OPAL_ELOG_RESEND if firmware supports it
powerpc/powernv: only call OPAL_RESEND_DUMP if firmware supports it
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
arch/powerpc
Otherwise firmware complains: OPAL: Called with bad token 74 !
as not all OPAL systems have the ability to resend error logs.
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-elog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Not all OPAL platforms support resending system dumps, so check
that current firmware supports it first. Otherwise we get firmware
complaining:
OPAL: Called with bad token 91 !
Signed-off-by: Stewart Smith stew...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
1
Michael Ellerman m...@ellerman.id.au writes:
I'm going to be a total pain, and suggest that this is the wrong approach :)
I was on board until patch 15, where you have to add an #ifdef SKIBOOT to
guard
an include, and you have to remove an include on the Linux side.
(the Linux include was
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
On 02/18/2015 05:33 AM, Stewart Smith wrote:
This series fixes three possible warnings that OPAL firmware would emit
when booting on hardware/simulator that didn't support certain functionality.
The correct thing for Linux to do
hegdevas...@linux.vnet.ibm.com
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
(well, it boots, interacts with firmware. I didn't go and look at the
LEDs themselves).
___
Linuxppc-dev mailing list
...@linux.vnet.ibm.com
Signed-off-by: Vasant Hegde hegdevas...@linux.vnet.ibm.com
I also just merged the skiboot side of these calls.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
(well, it boots, interacts with firmware. I didn't go and look at the
LEDs
Madhavan Srinivasan ma...@linux.vnet.ibm.com writes:
Nest Counters can be configured via PORE Engine and OPAL
provides an interface call to it. PORE Engine also does the
work of moving the counter data to memory.
Do you have the associated skiboot patch that implements this firmware
call? I
(that we care
about).
In related news.. I should poke the simulator guys.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Cedric Le Goater c...@fr.ibm.com writes:
The sensor service in OPAL only handles one FSP request at a time and
returns OPAL_BUSY if one is already in progress. The lock covers this case
but we could also remove it return EBUSY to the driver or even retry the
call. That might be dangerous
Michael Ellerman m...@ellerman.id.au writes:
Anton has a busy ppc64le KVM box where guests sometimes hit the infamous
kernel BUG at kernel/smpboot.c:134! issue during boot:
BUG_ON(td-cpu != smp_processor_id());
Basically a per CPU hotplug thread scheduled on the wrong CPU. The oops
output
Cédric Le Goater c...@fr.ibm.com writes:
On Open Power systems, such call fails in OPAL :
OPAL: Called with bad token 101 !
The check on the OPAL_UNREGISTER_DUMP_REGION call is added for
symmetry. I did not see any errors for it.
I've already put in a patch to squash this:
Message-Id:
Cedric Le Goater c...@fr.ibm.com writes:
On 02/25/2015 10:16 PM, Stewart Smith wrote:
Cédric Le Goater c...@fr.ibm.com writes:
On Open Power systems, such call fails in OPAL :
OPAL: Called with bad token 101 !
The check on the OPAL_UNREGISTER_DUMP_REGION call is added for
symmetry. I
By building a gcov enabled skiboot, which makes OPAL_START_CPU a whole
bunch slower (because gcov), I could really *really* reliably reproduce
this. With this patch, I cannot.
Tested-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Cédric Le Goater c...@fr.ibm.com writes:
Currently, when a sensor value is read, the kernel calls OPAL, which in
turn builds a message for the FSP, and waits for a message back.
The new device tree for OPAL sensors [1] adds new sensors that can be
read synchronously (core temperatures for
Signed-off-by: Jeremy Kerr j...@ozlabs.org
Signed-off-by: Joel Stanley j...@jms.id.au
Acking that firmware calls are merged into skiboot.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Signed-off-by: Jeremy Kerr j...@ozlabs.org
Acking that firmware interface is merged into skiboot and OPAL call
number is correct.
Acked-by: Stewart Smith stew...@linux.vnet.ibm.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https
Jacek Anaszewski j.anaszewsk...@gmail.com writes:
These device tree comes from out firmware ... which is immutable .
How the firmware is related to kernel? These bindings are for kernel,
not for the firmware.
DT bindings are compiled to *.dtb file which is concatenated with
zImage. During
Vasant Hegde hegdevas...@linux.vnet.ibm.com writes:
On 04/16/2015 12:20 AM, Stewart Smith wrote:
Jacek Anaszewski j.anaszew...@samsung.com writes:
+static struct platform_driver powernv_led_driver = {
+ .probe = powernv_led_probe,
+ .remove = powernv_led_remove,
+ .driver
Jacek Anaszewski j.anaszewsk...@gmail.com writes:
Is the DT node we are discussing used by some other drivers than the
LED class driver? Or is it required in this form by other components of
your platform?
OS kernels are the chief consumers, Linux being the overwhelmingly major
one here.
But
trigg mr.triggtr...@gmail.com writes:
--- a/arch/powerpc/include/asm/opal-api.h
+++ b/arch/powerpc/include/asm/opal-api.h
@@ -730,6 +730,36 @@ struct opal_i2c_request {
__be64 buffer_ra; /* Buffer real address */
};
+/*
+ * EPOW status sharing (OPAL and the host)
+
Jacek Anaszewski j.anaszew...@samsung.com writes:
+static struct platform_driver powernv_led_driver = {
+.probe = powernv_led_probe,
+.remove = powernv_led_remove,
+.driver = {
+.name = powernv-led-driver,
+.owner = THIS_MODULE,
+
Michael Ellerman m...@ellerman.id.au writes:
The only current place I could think this could be remotely possible
would be in simulator... and we should instead make the OPAL calls work
properly in the simulator for all the RTAS functionality (that we care
about).
If you mean mambo, I tested
stop reason before
panic.
Signed-off-by: Mahesh Salgaonkar mah...@linux.vnet.ibm.com
Acked in a the-api-is-present-in-firmware capacity.
Although patch should be against opal-api.h now rather than opal.h, so
that needs fixing before merging.
So,
Somewhat-Nearly-Acked-by: Stewart Smith stew
Vipin K Parashar vi...@linux.vnet.ibm.com writes:
This patch adds support for FSP (Flexible Service Processor)
EPOW (Early Power Off Warning) and DPO (Delayed Power Off) events for
Not restricted to FSP systems, it's a generic OPAL API that any platform
could implement.
1 - 100 of 250 matches
Mail list logo