Re: [PATCH] cpuidle/powernv : Add Description for cpuidle state

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.

Re: [PATCH] cpuidle/powernv : Add Description for cpuidle state

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.

Re: [PATCH] powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"

Colin King <colin.k...@canonical.com> writes: > From: Colin Ian King <colin.k...@canonical.com> > > Trivial fix to spelling mistake in hmi_error_types text > > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Reviewed-by: Stewart Smith <stew...@li

Re: [PATCH] powerpc-opal: fix spelling mistake "Uniterrupted" -> "Uninterrupted"

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.

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

that one). The idea behind that is 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.

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

quot;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.

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

head to stable? It means that for single threaded 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.

Re: [PATCH] cpuidle/powernv : init all present cpus for deep states

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.

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

any(policy->cpus, set_pstate, _data, 1); > + smp_call_function_any(policy->cpus, set_pstate, _data, 0); > } Should this have: Fixes: eaa2c3aeef83f and CC stable v4.7+ ? -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH] cpufreq: powernv: Fix the hardlockup by synchronus smp_call in timer interrupt

r(struct timer_list *t) > spin_unlock(>gpstate_lock); > > /* Timer may get migrated to a different cpu on cpu hot unplug */ > - smp_call_function_any(policy->cpus, set_pstate, _data, 1); > + smp_call_function_any(policy->cpus, set_pstate, _data, 0); > } Should this have: Fixes: eaa2c3aeef83f and CC stable v4.7+ ? -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

; > Fixes : 1e1601b38e6e ("powerpc/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.

Re: [PATCH] cpuidle/powernv : Restore different PSSCR for idle and hotplug

t;powerpc/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.

Re: [PATCH] powerpc/powernv : Add support to enable sensor groups

generic sensors API? >> > > Disabling/Enabling sensor groups is not supported in the current generic > 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.

Re: [PATCH] powerpc/powernv : Add support to enable sensor groups

c > 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.

Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc

Anju T Sudhakar <a...@linux.vnet.ibm.com> writes: > On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote: >> Michael Ellerman <m...@ellerman.id.au> writes: >>> Anju T Sudhakar <a...@linux.vnet.ibm.com> writes: >>> >>>> Add a

Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc

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)

Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc

ight thing and nothing special in kernel. i.e. not to merge this. -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc

ch/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. i.e. not to me

Re: [PATCH] powernv: Add OCC driver to mmap sensor area

already have two ways of exposing 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.

Re: [PATCH] powernv: Add OCC driver to mmap sensor area

ensors to Linux: the OPAL_SENSOR API and the IMC API. Why this method and not use the existing ones? -- Stewart Smith OPAL Architect, IBM.

[PATCH] drivers: of: increase MAX_RESERVED_REGIONS to 32

th "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 <stew...@linux.vnet.ibm.com> --- drivers/of/of_res

[PATCH] drivers: of: increase MAX_RESERVED_REGIONS to 32

th "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 file change

Re: [PATCH] drivers: of: static DT reservations incorrectly added to dynamic list

Rob Herring <r...@kernel.org> writes: > On Thu, Sep 14, 2017 at 5:24 AM, Stewart Smith > <stew...@linux.vnet.ibm.com> wrote: >> There are two types of memory reservations firmware can ask the kernel >> to make in the device tree: static and dynamic. >> S

Re: [PATCH] drivers: of: static DT reservations incorrectly added to dynamic list

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

[PATCH] drivers: of: static DT reservations incorrectly added to dynamic list

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 <stew...@linux.vnet.ibm.com> --- NOTE: I've done only fairly limited testing of this on POWER, I certainly haven't tested

[PATCH] drivers: of: static DT reservations incorrectly added to dynamic list

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 tested on ARM or *anything* with dynamic

Re: [PATCH V8 1/3] powernv: powercap: Add support for powercap framework

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.

Re: [PATCH V8 1/3] powernv: powercap: Add support for powercap framework

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.

[PATCH] doc: Document suitability of IBM Verse for kernel development

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 <s

[PATCH] doc: Document suitability of IBM Verse for kernel development

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

Re: [PATCH v8 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

n, we'd have no way to detect that and we'd fail silently by overwriting memory. -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH v8 07/10] powerpc/perf: PMU functions for Core IMC and hotplugging

t that and we'd fail silently by overwriting memory. -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

if the class exists but init is a no-op, then 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.

Re: [PATCH v8 05/10] powerpc/perf: IMC pmu cpumask and cpuhotplug support

L_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.

Re: [PATCH v8 02/10] powerpc/powernv: Autoload IMC device driver module

; + * "/reserved-memory" node. > + */ > + for (dn = of_find_node_by_name(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", _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.

Re: [PATCH v8 02/10] powerpc/powernv: Autoload IMC device driver module

,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", _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.

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

on boot. We may hot plug/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.

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

g 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.

Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events

ompatible 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.

Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events

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.

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

+#include > + > +#define IMC_MAX_CHIPS32 > +#define IMC_MAX_PMUS 32 > +#define IMC_MAX_PMU_NAME_LEN 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.

Re: [PATCH v6 01/11] powerpc/powernv: Data structure and macros definitions

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.

Re: [PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

uot;); > + if (!rm_node) > + goto err; > + > + for_each_child_of_node(rm_node, child) { > + if (of_property_read_string_index(child, "name", 0, > + _name)) > + continue; > +

Re: [PATCH v6 02/11] powerpc/powernv: Autoload IMC device driver module

(child, "name", 0, > + _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.

Re: [PATCHv3 4/4] MAINTAINERS: Remove powerpc's opal match

end up missing some code, what about this instead: Remove OPAL regex in powerpc to avoid false match Signed-off-by: Stewart Smith <stew...@linux.vnet.ibm.com> --- MAINTAINERS |8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 39

Re: [PATCHv3 4/4] MAINTAINERS: Remove powerpc's opal match

hat 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 +++ b/MAINTAINERS @@ -7393,18

Re: [PATCH 2/2] powernv: Pass PSSCR value and mask to power9_idle_stop

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.

Re: [PATCH 2/2] powernv: Pass PSSCR value and mask to power9_idle_stop

; } > } > > > > 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.

Re: [PATCH 1/4] dt-bindings: add doc for ibm,hotplug-aperture

nged, 26 insertions(+) >> create mode 100644 >> Documentation/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.

Re: [PATCH 1/4] dt-bindings: add doc for ibm,hotplug-aperture

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.

Re: [RFC 0/3] extend kexec_file_load system call

gt; not > require 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.

Re: [RFC 0/3] extend kexec_file_load system call

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.

Re: [RFC 0/3] extend kexec_file_load system call

Ard Biesheuvel <ard.biesheu...@linaro.org> writes: > On 13 July 2016 at 09:36, Russell King - ARM Linux > <li...@armlinux.org.uk> wrote: >> On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >>> Russell King - ARM Linux <li...@armlinux.org.uk> w

Re: [RFC 0/3] extend kexec_file_load system call

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: >

Re: [RFC 0/3] extend kexec_file_load system call

Russell King - ARM Linux <li...@armlinux.org.uk> writes: > On Wed, Jul 13, 2016 at 02:59:51PM +1000, Stewart Smith wrote: >> Russell King - ARM Linux <li...@armlinux.org.uk> writes: >> > On Tue, Jul 12, 2016 at 10:58:05PM +0200, Petr Tesarik wrote: >> >

Re: [RFC 0/3] extend kexec_file_load system call

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 example of

Re: [RFC 0/3] extend kexec_file_load system call

er. 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.

Re: [RFC 0/3] extend kexec_file_load system call

el 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.

Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS

So, I assume that this license is compatible with the GPLv2? https://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.

Re: [PATCH 1/2] crypto: vmx - Adding asm subroutines for XTS

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.

Re: [RFC 0/3] extend kexec_file_load system call

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.

Re: [RFC 0/3] extend kexec_file_load system call

uses the same console that >> petitboot 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.

Re: [RFC 0/3] extend kexec_file_load system call

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.

Re: [RFC 0/3] extend kexec_file_load system call

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.

Re: [PATCH V5 2/3] powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msg

th a dumb idea and a bug? otherwise (including if above change is made) Acked-by: Stewart Smith <stew...@linux.vnet.ibm.com> -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH V5 2/3] powerpc/opal: Add inline function to get rc from an ASYNC_COMP opal_msg

ise (including if above change is made) Acked-by: Stewart Smith -- Stewart Smith OPAL Architect, IBM.

Re: powerpc/nvram: Fix an incorrect partition merge

mware. :) It is. PAPR says we format NVRAM when it's corrupted. This is also true for NVRAM for PowerNV (not just pseries guest). -- Stewart Smith OPAL Architect, IBM.

Re: powerpc/nvram: Fix an incorrect partition merge

VRAM when it's corrupted. This is also true for NVRAM for PowerNV (not just pseries guest). -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

here we're all about OPAL. With a slight change to the commit message, Acked-by: Stewart Smith <stew...@linux.vnet.ibm.com> -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH V2 1/2] devicetree/bindings: Add binding for operator panel on FSP machines

a slight change to the commit message, Acked-by: Stewart Smith -- Stewart Smith OPAL Architect, IBM.

Re: [PATCH v2 2/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate

herit in hardware or software 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.

Re: [PATCH v2 2/2] cpufreq: powernv: Ramp-down global pstate slower than local-pstate

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.

Re: [PATCH] tty/hvc: Use IRQF_SHARED for hvc consoles

additional consoles > to start properly. > > Signed-off-by: Samuel Mendoza-Jonas <s...@mendozajonas.com> > Cc: <sta...@vger.kernel.org> # 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 bas

Re: [PATCH] tty/hvc: Use IRQF_SHARED for hvc consoles

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.

Re: [PATCH] add POWER Virtual Management Channel driver

undation hat on, I'll say that it's 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.

Re: [PATCH] add POWER Virtual Management Channel driver

umentation 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.

Re: [PATCH v3 0/2] cpufreq: powernv: Redesign the presentation of throttle notification

en this 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/

Re: [PATCH v3 0/2] cpufreq: powernv: Redesign the presentation of throttle notification

y should CC stable@ as we have seen this 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.ke

linux.conf.au 2016 Kernel Miniconf CFP

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

linux.conf.au 2016 Kernel Miniconf CFP

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

Re: [PATCH] selftests/powerpc: Add script to test HMI functionality

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

Re: [PATCH] selftests/powerpc: Add script to test HMI functionality

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

Re: [PATCH] powerpc: on crash, kexec'ed kernel needs all CPUs are online

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

Re: [PATCH] powerpc: on crash, kexec'ed kernel needs all CPUs are online

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.

Re: [PATCH] cpufreq: powernv: Increase the verbosity of OCC console messages

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

Re: [PATCH] cpufreq: powernv: Increase the verbosity of OCC console messages

Shilpasri G Bhat <shilpa.b...@linux.vnet.ibm.com> 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 <stew...@linux.vnet.ibm.com> > Signed-off-by:

Re: [PATCH v5 3/6] cpufreq: powernv: Register for OCC related opal_message notification

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

Re: [PATCH v5 3/6] cpufreq: powernv: Register for OCC related opal_message notification

Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com 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

Re: [PATCH v5 3/6] cpufreq: powernv: Register for OCC related opal_message notification

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 /*

Re: [PATCH v5 2/6] powerpc/powernv: Add definition of OPAL_MSG_OCC message type

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

Re: [PATCH v5 2/6] powerpc/powernv: Add definition of OPAL_MSG_OCC message type

Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com 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

Re: [PATCH v5 3/6] cpufreq: powernv: Register for OCC related opal_message notification

Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com 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

Re: [PATCH] rtc/rtc-opal: Enable alarms only when opal supports tpo

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 calls aren't

Re: [PATCH] rtc/rtc-opal: Enable alarms only when opal supports tpo

by setting opal_rtc_ops.read/set_alarm callback pointers only when tpo is supported. Acked-by: Michael Neuling mi...@neuling.org Acked-by: Neelesh Gupta neele...@linux.vnet.ibm.com Signed-off-by: Vaibhav Jain vaib...@linux.vnet.ibm.com Acked-by: Stewart Smith stew...@linux.vnet.ibm.com FWIW I'm

Re: [RFC PATCH 4/7]powerpc/powernv: Add OPAL support for Nest pmu

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

Re: [RFC PATCH 4/7]powerpc/powernv: Add OPAL support for Nest pmu

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

Re: [PATCH] powerpc/smp: Wait until secondaries are active & online

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 this patch, I cannot.

Re: [PATCH] powerpc/smp: Wait until secondaries are active & online

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

Re: [PATCH] powerpc/smp: Wait until secondaries are active online

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

Re: [PATCH] powerpc/smp: Wait until secondaries are active online

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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel

  1   2   >