ontinuing on is okay, as we have to keep compatibility with that firmware.
> --- a/include/linux/cpuidle.h
> +++ b/include/linux/cpuidle.h
> @@ -17,7 +17,7 @@
>
> #define CPUIDLE_STATE_MAX10
> #define CPUIDLE_NAME_LEN 16
> -#define CPUIDLE_DESC_LEN 32
> +#define CPUIDLE_DESC_LEN 60
Do we really get that long?
--
Stewart Smith
OPAL Architect, IBM.
Colin King writes:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in hmi_error_types text
>
> Signed-off-by: Colin Ian King
Reviewed-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
that you can answer "where did all my CPUs go?"
by looking at the device tree rather than having to know the platform
specific way of how guards are stored.
--
Stewart Smith
OPAL Architect, IBM.
d
workloads, if you guard out a CPU core you'll not get WoF, which means
that performance goes down when you wouldn't expect it to. Right?
--
Stewart Smith
OPAL Architect, IBM.
uct timer_list *t)
> spin_unlock(&gpstates->gpstate_lock);
>
> /* Timer may get migrated to a different cpu on cpu hot unplug */
> - smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
> + smp_call_function_any(policy->cpus, set_pstate, &freq_data, 0);
> }
Should this have:
Fixes: eaa2c3aeef83f
and CC stable v4.7+ ?
--
Stewart Smith
OPAL Architect, IBM.
owerpc/powernv/idle: Restore SPRs for deep idle
> states via stop API.")
This should CC stable ?
We'll need this to enable stop11 in firmware and not break things, right?
--
Stewart Smith
OPAL Architect, IBM.
eneric
> sensors
> API. And also we dont export all type of sensors in HWMON as not all of them
> are
> environment sensors (like performance).
Are there barriers to adding such concepts to the generic sensors API?
--
Stewart Smith
OPAL Architect, IBM.
Anju T Sudhakar writes:
> On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote:
>> Michael Ellerman writes:
>>> Anju T Sudhakar writes:
>>>
>>>> Add a kernel command line parameter option to disable In-Memory Collection
>>>> (IMC)
.ozlabs.org/patch/823249/
would fix the firmware implementation where the counters were already
running before the INIT/START calls, which are likely the cause of the
problems that this patch is trying to work around.
I propose we have the firmware do the right thing and nothing special in
kernel.
sensors
to Linux: the OPAL_SENSOR API and the IMC API.
Why this method and not use the existing ones?
--
Stewart Smith
OPAL Architect, IBM.
devices with "memory-region" properties.
A more future-proof fix is likely possible, although more invasive and this
simple fix is perfectly suitable in the meantime while a more future-proof
fix is developed.
Signed-off-by: Stewart Smith
---
drivers/of/of_reserved_mem.c | 2 +-
1 f
Rob Herring writes:
> On Thu, Sep 14, 2017 at 5:24 AM, Stewart Smith
> wrote:
>> There are two types of memory reservations firmware can ask the kernel
>> to make in the device tree: static and dynamic.
>> See Documentation/devicetree/bindings/reserved-memory/reserved
is a perfectly valid thing to do
(although I have not checked every real world device tree on the planet
for this condition)
Fixes: 3f0c8206644836e4f10a6b9fc47cda6a9a372f9b
Signed-off-by: Stewart Smith
---
NOTE: I've done only fairly limited testing of this on POWER, I
certainly haven't
thing, you *could* go
and set a differnt powercap 180 times concurrently and we should do the
right thing in skiboot... but then you're sitting in skiboot rather than
sitting in linux being able to go run some other task on the thread.
--
Stewart Smith
OPAL Architect, IBM.
IBM Verse is a web UI around Lotus Domino mail servers (much like
the Lotus Notes client talks to Domino servers).
For various reasons, it is not at all suitable for kernel development,
all of which have been raised (repeatedly) internally.
Signed-off-by: Stewart Smith
---
Documentation
detect that and we'd fail silently by
overwriting memory.
--
Stewart Smith
OPAL Architect, IBM.
n OPAL_IMC_COUNTERS_INIT should return
OPAL_SUCCESS and just do nothing. This future proofs everything, and the
API is that one *must* call _INIT before start.
--
Stewart Smith
OPAL Architect, IBM.
ame(rm_node, "ibm,homer-image"); dn;
> + dn = of_find_node_by_name(dn, "ibm,homer-image")) {
> +
> + /* Get the chip id to which the above homer region belongs to */
> + if (of_property_read_u32(dn, "ibm,chip-id", &chip_id))
> + goto err;
So, I was thinking on this (and should probably comment on the firmware
side as well).
I'd prefer an OPAL interface where instead of looking up where
ibm,homer-image is, we provide the kernel with a base address and then
have offsets into it.
That way, we don't tie the kernel code to counters that are only in the
HOMER region.
--
Stewart Smith
OPAL Architect, IBM.
unplug CPUs, but we're not doing that from a hardware
level, what CPUs you get in the DT on PowerNV on boot is all you're
getting.
--
Stewart Smith
OPAL Architect, IBM.
ible node under the
top level ibm,opal-in-memory-counters node? (i'm not convinced that
having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
ibm,imc-counters-thread as I see in the dts is correct though, as
they're all accessed exactly the same way?)
--
Stewart Smith
OPAL Architect, IBM.
256
Why do we need a max length? We get the actual lengths from the device
tree, so we know at each point in time what the length of any new string
should be, right?
Otherwise you appear to be, in the general case, using 10x the memory
than you could.
--
Stewart Smith
OPAL Architect, IBM.
if (of_property_read_string_index(child, "name", 0,
> + &node_name))
> + continue;
> + if (strncmp("ibm,homer-image", node_name,
> + strlen("ibm,homer-image")))
> + continue;
A better way to do this would be to reference the memory region, like
what's shown in
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
just reference the phandle of the memory region.
seeing as these are per chip, why not just have something linking
together chip-id and the IMC layout node?
--
Stewart Smith
OPAL Architect, IBM.
missing some code, what about this instead:
Remove OPAL regex in powerpc to avoid false match
Signed-off-by: Stewart Smith
---
MAINTAINERS |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3960e7f..25ed25a 100644
--- a/MAINTAINERS
+++
;
> }
> }
>
>
>
> Is this approach ok ?
What if we just treat the 0xF state from firmware as special and set it
to DEFAULT_PSSCR_MASK in that case? That deals with old skiboot, new
kernel, and sets a pretty small special case that's easy to track into
the future as something we should watch out for.
Additionally, if we make skiboot set sane values in ~DEFAULT_PSSCR_MASK
for valid fields in PSSCR on boot/(also kexec?), then
we should end up in a situation where everything works with everything
(even if you don't get the best power saving). Specifically, new
skiboot, old kernel... but it looks like there's nothing currently
missing there
Should this patch also have Fixes: 3005c597ba4 and CC to stable?
--
Stewart Smith
OPAL Architect, IBM.
ocumentation/devicetree/bindings/powerpc/opal/hotplug-aperture.txt
Forgive me for being absent on the whole discussion here, but is this an
OPAL specific binding? If so, shouldn't the docs also appear in the
skiboot tree?
--
Stewart Smith
OPAL Architect, IBM.
e an additional step of signing it, since the running kernel already
> trusts it.
- using current view of the hardware, flattened into a new dtb.
This should already be trusted, as it's what we're running now (boot +
runtime changes)
--
Stewart Smith
OPAL Architect, IBM.
Ard Biesheuvel writes:
> On 13 July 2016 at 09:36, Russell King - ARM Linux
> wrote:
>> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>>> Russell King - ARM Linux writes:
>>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
>
Russell King - ARM Linux writes:
> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote:
>> Russell King - ARM Linux writes:
>> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote:
>> >> I'm not an expert on DTB, so I can't provide an
Our bootloader is a
linux kernel and initramfs with a UI (petitboot) - this means we never
have to write a device driver twice: write a kernel one and you're done
(for booting from the device and using it in your OS).
--
Stewart Smith
OPAL Architect, IBM.
ps://people.gnome.org/~markmc/openssl-and-the-gpl.html has an
explanation and points to:
https://www.openssl.org/docs/faq.html#LEGAL2
which makes it anything but clearer.
it appears the answer is "probably not, unless you have an explicit
exemption in your license"
--
Stewart Smith
OPAL Architect, IBM.
eeds to work out which console is being
interacted with in order to set up /chosen/linux,stdout-path correctly.
This specific option could be passed as a kernel command line to the
next kernel, yes. However, isn't the kernel command line also an attack
vector? Is *every* command line option safe?
> In general, tampering with the hardware inventory of a machine opens up
> a security hole, and one must be very cautious which modifications are
> allowed. You're giving this power to an (unsigned, hence untrusted)
> userspace application; Eric argues that only the kernel should have
> this power.
In the case of petitboot on OpenPOWER, this (will) be a signed and
trusted kernel and userspace and verified by a previous bit of firmware.
--
Stewart Smith
OPAL Architect, IBM.
tboot was configured to use (i.e., set the /chosen/linux,stdout-path
>> property). It also modifies the device tree to allow the kernel to inherit
>> Petitboot's Openfirmware framebuffer.
>
> Can some of this be done with the help of kernel command line options for
> second kernel?
how would this be any more secure?
Passing in an address for a framebuffer via command line option means
you could scribble over any bit of memory, which is the same kind of
damage you could do by modifying the device tree.
--
Stewart Smith
OPAL Architect, IBM.
ise (including if above change is made)
Acked-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
mat NVRAM when it's corrupted. This is also true
for NVRAM for PowerNV (not just pseries guest).
--
Stewart Smith
OPAL Architect, IBM.
PAL.
With a slight change to the commit message,
Acked-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
e that this is computed from?
> +/* Interval after which the timer is queued to bring down global pstate */
> +#define GPSTATE_TIMER_INTERVAL 2000
in ms?
--
Stewart Smith
OPAL Architect, IBM.
to start properly.
>
> Signed-off-by: Samuel Mendoza-Jonas
> Cc: # 4.1.x-
Tested on 4.4.6 - seemed to stop (some of) the problems I was having
when using it as a kernel for the bootloader on a FSP based POWER8
system.
Tested-by: Stewart Smith
--
Stewart Smith
OPAL Architect, IBM.
a
work-in-progress getting all this documentation in order.
The questions of if it's a sensible hypervisor to partition interface
and if it's a sensible userspace API are open for debate :)
Would we implement this way of communicating between a KVM guest and the
host linux system? If not, then it's probably not a generally good
idea. That being said, it seems to be what already exists in PowerVM
--
Stewart Smith
OPAL Architect, IBM.
his on some machines, at
least in the lab.
--
Stewart Smith
OPAL Architect, IBM.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux.conf.au 2016 in Geelong will have a kernel miniconf. The format is
part talks, part unconference.
The miniconf will be all day Monday.
Like previous years, a mixture of organised talks and impromptu
discussion and sessions can provide a good mix.
CFP open until Jan 20th. Unconference topic
Daniel Axtens writes:
> I just realised I sent my reply to Denis not the list - apologies. This
> info goes for v2 as well.
>
> > Could you explain why it's useful, and what it's useful for. Moreover,
> > it's POWER8 feature, right?
>
> I'm not sure whether you're asking about the script or
David Gibson writes:
>> > opal/powernv:
>> > https://github.com/open-power/skiboot/commit/9ee56b5
>>
>> Very interesting. Is there a way to have a firmware with the fix ?
>
> From Laurent's analysis of the crash, I don't think this will be
> relevant either, but I'm not sure. It would be very in
Shilpasri G Bhat writes:
> Modify the OCC reset/load/active event message to make it clearer for
> the user to understand the event and effect of the event.
>
> Suggested-by: Stewart Smith
> Signed-off-by: Shilpasri G Bhat
Acked-by: Stewart Smith
--
To unsubscribe from this
Shilpasri G Bhat writes:
>> Also, do we export this information via sysfs somewhere? It would seem
>> to want to go along with other cpufreq/cpu info there.
>
> No we don't export the throttling status of the cpu via sysfs. Since the
> throttling state is common across the chip, the per_cpu export
Shilpasri G Bhat writes:
> diff --git a/drivers/cpufreq/powernv-cpufreq.c
> b/drivers/cpufreq/powernv-cpufreq.c
> index d0c18c9..a634199 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -33,6 +33,7 @@
> #include
> #include
> #include /* Require
Shilpasri G Bhat writes:
> Add OPAL_MSG_OCC message definition to opal_message_type to receive
> OCC events like reset, load and throttled. Host performance can be
> affected when OCC is reset or OCC throttles the max Pstate.
> We can register to opal_message_notifier to receive OPAL_MSG_OCC type
>
> This patch fixes this issue by setting opal_rtc_ops.read/set_alarm
> callback pointers only when tpo is supported.
>
> Acked-by: Michael Neuling
> Acked-by: Neelesh Gupta
> Signed-off-by: Vaibhav Jain
Acked-by: Stewart Smith
FWIW I'm updating OPAL docs with this. The TPO ca
Madhavan Srinivasan 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 haven't seen it on th
6f ("sched: Fix hotplug vs. set_cpus_allowed_ptr()")
> Signed-off-by: Michael Ellerman
> Signed-off-by: Anton Blanchard
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 th
Michael Ellerman 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 confirms
Vasant Hegde 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
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
---
arch/powerpc/platforms/powernv/opal.c |6 +-
se
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/po
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
---
arch/powerpc/platforms/powernv/opal-elog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ar
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
---
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
1 file changed, 2
.
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
---
arch/powerpc/platforms/powernv/opal-elog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ar
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
---
arch/powerpc/platforms/powernv/opal-dump.c |3 ++-
1 file changed, 2
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
---
arch/powerpc/platforms/powernv/opal.c |6 +-
Michael Ellerman 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 actually not use
This finally syncs the content of opal.h between linux and firmware
Signed-off-by: Stewart Smith
---
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 68ce7ef
Signed-off-by: Stewart Smith
---
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/opal.h
+++ b/arch/powerpc
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
---
arch/powerpc/include/asm/opal-api.h
reduces the diff between linux and firmware header files significantly.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 51 +++
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc
Some enums in firmware opal.h were missing from linux opal.h, add them.
Signed-off-by: Stewart Smith
---
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/powerpc/include/asm/opal.h
Signed-off-by: Stewart Smith
---
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/include/asm/opal.h
+++ b/arch
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
---
arch/powerpc/include/asm/opal.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b
For whatever reason these structures were in different places.
Now they are not.
Signed-off-by: Stewart Smith
---
arch/powerpc/include/asm/opal.h | 48 +++
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/include/asm/opal.h b
e.
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:
Adds OPAL_MSG_DPO and docs for OPAL_MSG_SHUTDOWN
Signed-off-by: Stewart Smith
---
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..2deaadf 100644
--- a/arch
Signed-off-by: Stewart Smith
---
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
index c4009dd..172d08e
Signed-off-by: Stewart Smith
---
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/opal.h
+++ b/arch/powerpc
Signed-off-by: Stewart Smith
---
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/powerpc/include/asm/opal.h
Signed-off-by: Stewart Smith
---
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/opal.h
+++ b/arch/powerpc
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
---
arch/powerpc/include/asm/opal.h | 32
1 file
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
---
arch/powerpc/include/asm/opal.h | 52
Signed-off-by: Stewart Smith
---
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/opal.h
+++ b/arch/powerpc
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
---
arch/powerpc/i
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
---
arch/powerpc/include/asm/opal.h |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm
rthy
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message t
nd falling back looks good.
(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
--
To unsubscri
Preeti U Murthy writes:
> On 01/28/2015 02:45 PM, Stewart Smith wrote:
>> Preeti U Murthy writes:
>>> The device tree now exposes the residency values for different idle states.
>>> Read
>>> these values instead of calculating residency from the latency va
Pranith Kumar writes:
> On Thu, Jan 22, 2015 at 12:19 AM, Michael Ellerman
> 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 values and skip registering the dump
on crash every time you boot.
Reviewed-by: Stewart Smith
> ---
> 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/opal.c
> index f10b9ec..1db11
Vasant Hegde 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 registers kernel log
> buffer.
n Fontenot
> Signed-off-by: Greg Kurz
Acked-by: Stewart Smith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Benjamin Herrenschmidt writes:
> On Mon, 2014-03-31 at 09:27 +1100, Stewart Smith wrote:
>> Greg Kurz writes:
>> > struct rtas_error_log {
>> > +#ifdef __BIG_ENDIAN__
>> > + /* Byte 0 */
>> >unsigned long version:8;/* Architect
Greg Kurz writes:
> On Mon, 31 Mar 2014 09:27:16 +1100
> Stewart Smith wrote:
>> Greg Kurz writes:
>> > struct rtas_error_log {
>> > +#ifdef __BIG_ENDIAN__
>> > + /* Byte 0 */
>> >unsigned long version:8;/* Architectural v
Greg Kurz 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 the compiler change
Tejun Heo writes:
> On Mon, Mar 17, 2014 at 06:05:54PM -0400, Tejun Heo wrote:
>> I think this is being blown out of proportion. It was a rarely used
>> API and converting to the new one is mostly trivial which can be
>
> So, looked at the failed code. The only necessary change seems to be
> cal
Greg KH writes:
> On Tue, Mar 18, 2014 at 07:33:30AM +1100, Benjamin Herrenschmidt wrote:
>> On Mon, 2014-03-17 at 11:33 -0700, Greg KH wrote:
>>
>> > There were only 3 (or 4), users of this api, and no new ones had been
>> > added in _years_, it's a very obscure thing, and odds are, it wouldn't
Previously, many years ago, this was done in series which was fine,
but things moved to be done in parallel and with many disks in a system
it can be hard to see which disk spun up and which one didn't as the
printk messages were all mixed together.
Signed-off-by: Stewart Smith
---
drivers
worked" although we do seem to get issues
on ext3).
I have a (casually stupid) simulation program... although I've observed
little to no problems on all my XFS tests using it.
--
Stewart Smith, Senior Software Engineer (MySQL Cluster)
MySQL AB, www.mysql.com
Office: +1408213
ing happening.
yes. Keep in mind that the binlog grows in file size too... so this has
to sync all the metadata as well (ick, i know).
--
Stewart Smith, Senior Software Engineer
MySQL AB, www.mysql.com
Office: +14082136540 Ext: 6616
VoIP: [EMAIL PROTECTED]
Mobile: +61 4 3 8844 332
Jum
94 matches
Mail list logo