Re: [PATCH v2 0/9] Convert the remaining text files to ReST and add SPDX for GFDL

On Tue, Jun 23, 2020 at 4:53 AM Mauro Carvalho Chehab wrote: > > The main goal of this series is to finish the ReST conversion. After this > series, we have just those files still in plain old format: > > - Documentation/RCU/RTFP.txt > - Documentation/atomic_bitops.txt > -

Re: [PATCH v2 2/9] LICENSES: add GFDL licenses

Hi Mauro, On Tue, Jun 23, 2020 at 4:53 AM Mauro Carvalho Chehab wrote: > > Those are used on some documentation texts. > > Signed-off-by: Mauro Carvalho Chehab > --- > LICENSES/deprecated/GFDL-1.1+ | 366 ++ > LICENSES/deprecated/GFDL-1.2 | 408 +

Re: [PATCH v2 1/3] treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi headers

; @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > > #ifndef __QCOM_FASTRPC_H__ > #define __QCOM_FASTRPC_H__ > diff --git a/include/uapi/rdma/rvt-abi.h b/include/uapi/rdma/rvt-abi.h > index 7328293c715c..7c05a02d2be5 100644 > --- a/include/uapi/rdma/rvt-abi.h > +++ b/include/uapi/rdma/rvt-abi.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */ > +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR > BSD-3-Clause) */ > > /* > * This file contains defines, structures, etc. that are used > diff --git a/include/uapi/rdma/siw-abi.h b/include/uapi/rdma/siw-abi.h > index 3dd8071ace7b..7de68f1dc707 100644 > --- a/include/uapi/rdma/siw-abi.h > +++ b/include/uapi/rdma/siw-abi.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 or BSD-3-Clause */ > +/* SPDX-License-Identifier: (GPL-2.0 WITH Linux-syscall-note) or > BSD-3-Clause */ > > /* Authors: Bernard Metzler */ > /* Copyright (c) 2008-2019, IBM Corporation */ > diff --git a/include/uapi/scsi/scsi_bsg_ufs.h > b/include/uapi/scsi/scsi_bsg_ufs.h > index 17c7abd0803a..9988db6ad244 100644 > --- a/include/uapi/scsi/scsi_bsg_ufs.h > +++ b/include/uapi/scsi/scsi_bsg_ufs.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > /* > * UFS Transport SGIO v4 BSG Message Support > * > diff --git a/include/uapi/sound/skl-tplg-interface.h > b/include/uapi/sound/skl-tplg-interface.h > index f39352cef382..9eee32f5e407 100644 > --- a/include/uapi/sound/skl-tplg-interface.h > +++ b/include/uapi/sound/skl-tplg-interface.h > @@ -1,4 +1,4 @@ > -/* SPDX-License-Identifier: GPL-2.0 */ > +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ > /* > * skl-tplg-interface.h - Intel DSP FW private data interface > * > -- > 2.17.1 > Reviewed-by: Kate Stewart

I need your assistance to invest!

best regards, Miss Lisa Stewart

Attention.

Compliments of the day ; I have a business proposition for you which I sent you previously,I do not know if you received it? Please do find it proper to write me if your email is still active. Yours Faithfully,Barr. Alexander Stewart.

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

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.

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

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 V2 3/7] LICENSES: Add Apache 2.0 license text

Apache-2.0.html#licenseText >> >> Signed-off-by: Thomas Gleixner > > Reviewed-by: Greg Kroah-Hartman Reviewed-by: Kate Stewart

Re: [patch V2 4/7] LICENSES: Add CDDL-1.0 license text

nseText >> >> Signed-off-by: Thomas Gleixner > > Reviewed-by: Greg Kroah-Hartman Reviewed-by: Kate Stewart

Re: [patch V2 5/7] LICENSES: Add CC-BY-SA-4.0 license text

-BY-SA-4.0.html#licenseText >> >> Signed-off-by: Thomas Gleixner > > Reviewed-by: Greg Kroah-Hartman > Reviewed-by: Kate Stewart

Re: [patch V2 6/7] LICENSES: Add Linux-OpenIB license text

; OpenIB.org license is a true match to BSD-2-Clause. > > The license text was copied from: > > https://spdx.org/licenses/Linux-OpenIB.html#licenseText > > Signed-off-by: Thomas Gleixner Reviewed-by: Kate Stewart

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

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.

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

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.

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

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.

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

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

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

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.

[PATCH] drivers: of: increase MAX_RESERVED_REGIONS to 32

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

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

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

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

Cyril Bur writes: > This is more for MPE and Stewart: > If there is some mutual exclusion that needs to happen, it should be > done in skiboot. We've had problems in the past with double entering > skiboot and hard to interpret errors ending up in userspace, this > solves th

[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

detect 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

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.

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

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.

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

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 03/11] powerpc/powernv: Detect supported IMC units and its events

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.

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

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.

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

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

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

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

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

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

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

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.

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

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.

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

mat NVRAM 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

PAL. With 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

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.

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

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 v3 0/2] cpufreq: powernv: Redesign the presentation of throttle notification

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

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] 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 in

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 this

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 export

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

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] rtc/rtc-opal: Enable alarms only when opal supports tpo

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

PROBLEM: Kernel null pointer dereference when sandboxing

love to run any tests or help any way I can to fix this bug. I understand if maintainers are too busy to reply or fix this bug. Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.

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 th

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

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

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 0/3] powerpc/powernv: Correctly detect optional OPAL calls

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

[PATCH 1/3] powerpc/powernv: only register log if OPAL supports doing so

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

[PATCH 0/3] powerpc/powernv: Correctly detect optional OPAL calls

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

[PATCH 2/3] powerpc/powernv: only call OPAL_ELOG_RESEND if firmware supports it

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

[PATCH 3/3] powerpc/powernv: only call OPAL_RESEND_DUMP if firmware supports it

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

[PATCH 0/3] Silence "OPAL called with invalid token" errors

. 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

[PATCH 2/3] powerpc/powernv: only call OPAL_ELOG_RESEND if firmware supports it

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

[PATCH 3/3] powerpc/powernv: only call OPAL_RESEND_DUMP if firmware supports it

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

[PATCH 1/3] powerpc/powernv: only register log if OPAL supports doing so

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

Re: [PATCH 00/18] sync opal.h with firmware

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

[PATCH 18/18] powerpc/powernv: s/OpalM64EnableAction/OpalM64Action/ and __be64 annotation

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

[PATCH 07/18] powerpc/powernv: make whitespace for OPAL_PM_* defines match firmware

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

[PATCH 10/18] powerpc/powernv: move OPAL API prototypes to opal-api.h

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

[PATCH 05/18] powerpc/powernv: synchronize opal.h whitespace with firmware

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

[PATCH 13/18] powerpc/powernv: add remaining missing enums to opal.h

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

[PATCH 06/18] powerpc/powernv: move OPAL_DUMP_REGION defines in opal.h to same place as in firmware 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

[PATCH 01/18] powerpc/powernv: sync OPAL API tokens with skiboot

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

[PATCH 04/18] powerpc/powernv: relocate struct opal_sg_entry in opal.h to same place it is in firmware

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

[PATCH 00/18] sync opal.h with firmware

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:

[PATCH 09/18] powerpc/powernv: match enum OpalMessageType with firmware

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

[PATCH 16/18] powerpc/powernv: move SG_ENTRIES_PER_NODE to linux-specific opal-api.h

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

[PATCH 11/18] powerpc/powernv: make whitespace in enum OpalSysparamPerm match 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 4373010..240ee1c 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc

[PATCH 14/18] powerpc/powernv: sync comments and whitespace in opal.h with firmware

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

[PATCH 17/18] powerpc/powernv: s/u8/uint8_t/ to match firmware in 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

[PATCH 08/18] powerpc/powernv: Move OpalSysparamPerm,OpalMessageType in opal.h to match firmware

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

[PATCH 12/18] powerpc/powernv: add CAPI and EPOW parts to opal.h

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

[PATCH 15/18] powerpc/powernv: sync #includes in opal.h with firmware

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

[PATCH 03/18] powerpc/powernv: s/OPAL_PCI_SET_PHB_CXL_MODE/OPAL_PCI_SET_PHB_CAPI_MODE/ to match firmware

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

[PATCH 02/18] powerpc/powernv: synchronize OPAL calls and return codes with firmware

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

Re: [PATCH V3] cpuidle/powernv: Read target_residency value of idle states from DT if available

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

Re: [PATCH V2] cpuidle/powernv: Read target_residency value of idle states from DT if available

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

Re: [PATCH V2] cpuidle/powernv: Read target_residency value of idle states from DT if available

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

Re: [PATCH v2 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n

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

Re: [PATCH 2/2] powerpc/powernv: Skip registering log region when CONFIG_PRINTK=n

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

When should I not use CLONE_IO?

f them? Even if the threads sharing the same I/O context must use the same scheduler can they have different priorities? Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org Mor

Re: How can I parse the command name from /proc//stat?

Thank you, I dislike the idea of relying upon stat never gaining any other part that uses ) but that would work instead of using status. -- 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://vg

How can I parse the command name from /proc//stat?

e works totally correctly. Thank you, Steven Stewart-Gallus -- 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 1/1] ipc/mqueue.c: Drag unneeded code out of locks

t still needs improvement? Finally, please don't ignore the rest of my message. Even if my patch isn't that good there are lots of ways to compromise and improve it such as adding tests, annotations and making it clearer. Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: se

Re: [PATCH 1/1] ipc/mqueue.c: Drag unneeded code out of locks

r the changes I made too it? Or that you'd want some more formal methods to make the code easier to verify? I suppose the area of code use a few extra sparse annotations. Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&q

Re: [PATCH 1/1] ipc/mqueue.c: Drag unneeded code out of locks

eue creation is not rejected then the resource user has to be accounted for right? And we can't add the resource to accounting if it is not created right? Thank you, Steven Stewart-Gallus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

  1   2   >