* Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
From: Dave Hansen @ 2018-05-16 17:01 UTC (permalink / raw)
To: Florian Weimer, Andy Lutomirski
Cc: Andy Lutomirski, linuxram, Linux-MM, Linux API, linux-x86_64,
linux-arch, X86 ML, linuxppc-dev
In-Reply-To: <c727a0da-dd5b-4ca2-375c-773ec550ab25@redhat.com>
On 05/14/2018 08:34 AM, Florian Weimer wrote:
>>> The initial PKRU value can currently be configured by the system
>>> administrator. I fear this approach has too many moving parts to be
>>> viable.
>>
>> Honestly, I think we should drop that option. I don’t see how we can
>> expect an administrator to do this usefully.
>
> I don't disagree—it makes things way less predictable in practice.
I originally put that thing in there to make Andy happy with the initial
permissions, and give us a way to back it out if something went wrong.
I have no objections to removing it either.
^ permalink raw reply
* Re: [PATCH v4 2/2] cxl: Report the tunneled operations status
From: Frederic Barrat @ 2018-05-16 16:47 UTC (permalink / raw)
To: Philippe Bergheaud, linuxppc-dev; +Cc: clombard, benh
In-Reply-To: <20180514082736.3699-2-felix@linux.ibm.com>
Le 14/05/2018 à 10:27, Philippe Bergheaud a écrit :
> Failure to synchronize the tunneled operations does not prevent
> the initialization of the cxl card. This patch reports the tunneled
> operations status via /sys.
>
> Signed-off-by: Philippe Bergheaud <felix@linux.ibm.com>
> ---
Thanks for adding the sysfs documentation.
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> v3: Added this patch to report the tunneled operations status.
>
> v4: Updated Documentation/ABI/testing/sysfs-class-cxl.
> ---
> Documentation/ABI/testing/sysfs-class-cxl | 8 ++++++++
> drivers/misc/cxl/cxl.h | 1 +
> drivers/misc/cxl/pci.c | 7 ++++++-
> drivers/misc/cxl/sysfs.c | 10 ++++++++++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl
> index 640f65e79ef1..8e69345c37cc 100644
> --- a/Documentation/ABI/testing/sysfs-class-cxl
> +++ b/Documentation/ABI/testing/sysfs-class-cxl
> @@ -244,3 +244,11 @@ Description: read only
> Returns 1 if the psl timebase register is synchronized
> with the core timebase register, 0 otherwise.
> Users: https://github.com/ibm-capi/libcxl
> +
> +What: /sys/class/cxl/<card>/tunneled_ops_supported
> +Date: May 2018
> +Contact: linuxppc-dev@lists.ozlabs.org
> +Description: read only
> + Returns 1 if tunneled operations are supported in capi mode,
> + 0 otherwise.
> +Users: https://github.com/ibm-capi/libcxl
> diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
> index a4c9c8297a6d..918d4fb742d1 100644
> --- a/drivers/misc/cxl/cxl.h
> +++ b/drivers/misc/cxl/cxl.h
> @@ -717,6 +717,7 @@ struct cxl {
> bool perst_select_user;
> bool perst_same_image;
> bool psl_timebase_synced;
> + bool tunneled_ops_supported;
>
> /*
> * number of contexts mapped on to this card. Possible values are:
> diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
> index 355c789406f7..008f50a0c465 100644
> --- a/drivers/misc/cxl/pci.c
> +++ b/drivers/misc/cxl/pci.c
> @@ -1742,9 +1742,14 @@ static int cxl_configure_adapter(struct cxl *adapter, struct pci_dev *dev)
> /* Required for devices using CAPP DMA mode, harmless for others */
> pci_set_master(dev);
>
> - if (cxl_is_power9())
> + adapter->tunneled_ops_supported = false;
> +
> + if (cxl_is_power9()) {
> if (pnv_pci_set_tunnel_bar(dev, 0x00020000E0000000ull, 1))
> dev_info(&dev->dev, "Tunneled operations unsupported\n");
> + else
> + adapter->tunneled_ops_supported = true;
> + }
>
> if ((rc = pnv_phb_to_cxl_mode(dev, adapter->native->sl_ops->capi_mode)))
> goto err;
> diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c
> index 95285b7f636f..4b5a4c5d3c01 100644
> --- a/drivers/misc/cxl/sysfs.c
> +++ b/drivers/misc/cxl/sysfs.c
> @@ -78,6 +78,15 @@ static ssize_t psl_timebase_synced_show(struct device *device,
> return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->psl_timebase_synced);
> }
>
> +static ssize_t tunneled_ops_supported_show(struct device *device,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + struct cxl *adapter = to_cxl_adapter(device);
> +
> + return scnprintf(buf, PAGE_SIZE, "%i\n", adapter->tunneled_ops_supported);
> +}
> +
> static ssize_t reset_adapter_store(struct device *device,
> struct device_attribute *attr,
> const char *buf, size_t count)
> @@ -183,6 +192,7 @@ static struct device_attribute adapter_attrs[] = {
> __ATTR_RO(base_image),
> __ATTR_RO(image_loaded),
> __ATTR_RO(psl_timebase_synced),
> + __ATTR_RO(tunneled_ops_supported),
> __ATTR_RW(load_image_on_perst),
> __ATTR_RW(perst_reloads_same_image),
> __ATTR(reset, S_IWUSR, NULL, reset_adapter_store),
>
^ permalink raw reply
* Re: [PATCH 7/7] cxlflash: Isolate external module dependencies
From: Matthew R. Ochs @ 2018-05-16 16:13 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065579-39079-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:06:19PM -0500, Uma Krishnan wrote:
> Depending on the underlying transport, cxlflash has a dependency on either
> the CXL or OCXL drivers, which are enabled via their Kconfig option.
> Instead of having a module wide dependency on these config options, it is
> better to isolate the object modules that are dependent on the CXL and OCXL
> drivers and adjust the module dependencies accordingly.
>
> This commit isolates the object files that are dependent on CXL and/or
> OCXL. The cxl/ocxl fops used in the core driver are tucked under an ifdef
> to avoid compilation errors.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 6/7] cxlflash: Abstract hardware dependent assignments
From: Matthew R. Ochs @ 2018-05-16 15:59 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065565-39041-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:06:05PM -0500, Uma Krishnan wrote:
> As a staging cleanup to support transport specific builds of the cxlflash
> module, relocate device dependent assignments to header files. This will
> avoid littering the core driver with conditional compilation logic.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 5/7] cxlflash: Add include guards to backend.h
From: Matthew R. Ochs @ 2018-05-16 15:58 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065551-39005-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:51PM -0500, Uma Krishnan wrote:
> The new header file, backend.h, that was recently added is missing
> the include guards. This commit adds the guards.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 3/7] cxlflash: Acquire semaphore before invoking ioctl services
From: Matthew R. Ochs @ 2018-05-16 15:54 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065522-38933-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:22PM -0500, Uma Krishnan wrote:
> When a superpipe process that makes use of virtual LUNs is terminated or
> killed abruptly, there is a possibility that the cxlflash driver could
> hang and deprive other operations on the adapter.
>
> The release fop registered to be invoked on a context close, detaches
> every LUN associated with the context. The underlying service to detach
> the LUN assumes it has been called with the read semaphore held, and
> releases the semaphore before any operation that could be time consuming.
>
> When invoked without holding the read semaphore, an opportunity is created
> for the semaphore's count to become negative when it is temporarily
> released during one of these potential lengthy operations. This negative
> count results in subsequent acquisition attempts taking forever, leading
> to the hang.
>
> To support the current design point of holding the semaphore on the
> ioctl() paths, the release fop should acquire it before invoking any
> ioctl services.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH 2/7] cxlflash: Limit the debug logs in the IO path
From: Matthew R. Ochs @ 2018-05-16 15:53 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065508-38897-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:05:08PM -0500, Uma Krishnan wrote:
> The kernel log can get filled with debug messages from send_cmd_ioarrin()
> when dynamic debug is enabled for the cxlflash module and there is a lot
> of legacy I/O traffic.
>
> While these messages are necessary to debug issues that involve command
> tracking, the abundance of data can overwrite other useful data in the
> log. The best option available is to limit the messages that should
> serve most of the common use cases.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] cpuidle/powernv : init all present cpus for deep states
From: Stewart Smith @ 2018-05-16 15:22 UTC (permalink / raw)
To: Akshay Adiga, linux-kernel, linuxppc-dev; +Cc: Akshay Adiga, npiggin, ego
In-Reply-To: <1526472134-23757-1-git-send-email-akshay.adiga@linux.vnet.ibm.com>
Akshay Adiga <akshay.adiga@linux.vnet.ibm.com> writes:
> Init all present cpus for deep states instead of "all possible" cpus.
> Init fails if the possible cpu is gaurded. Resulting in making only
> non-deep states available for cpuidle/hotplug.
Should this also 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.
^ permalink raw reply
* Re: [PATCH 1/7] cxlflash: Yield to active send threads
From: Matthew R. Ochs @ 2018-05-16 15:09 UTC (permalink / raw)
To: Uma Krishnan
Cc: linux-scsi, James Bottomley, Martin K. Petersen, Manoj N. Kumar,
linuxppc-dev, Andrew Donnellan, Frederic Barrat,
Christophe Lombard
In-Reply-To: <1526065486-38860-1-git-send-email-ukrishn@linux.vnet.ibm.com>
On Fri, May 11, 2018 at 02:04:46PM -0500, Uma Krishnan wrote:
> The following Oops may be encountered if the device is reset, i.e. EEH
> recovery, while there is heavy I/O traffic:
>
> 59:mon> t
> [c000200db64bb680] c008000009264c40 cxlflash_queuecommand+0x3b8/0x500
> [cxlflash]
> [c000200db64bb770] c00000000090d3b0 scsi_dispatch_cmd+0x130/0x2f0
> [c000200db64bb7f0] c00000000090fdd8 scsi_request_fn+0x3c8/0x8d0
> [c000200db64bb900] c00000000067f528 __blk_run_queue+0x68/0xb0
> [c000200db64bb930] c00000000067ab80 __elv_add_request+0x140/0x3c0
> [c000200db64bb9b0] c00000000068daac blk_execute_rq_nowait+0xec/0x1a0
> [c000200db64bba00] c00000000068dbb0 blk_execute_rq+0x50/0xe0
> [c000200db64bba50] c0000000006b2040 sg_io+0x1f0/0x520
> [c000200db64bbaf0] c0000000006b2e94 scsi_cmd_ioctl+0x534/0x610
> [c000200db64bbc20] c000000000926208 sd_ioctl+0x118/0x280
> [c000200db64bbcc0] c00000000069f7ac blkdev_ioctl+0x7fc/0xe30
> [c000200db64bbd20] c000000000439204 block_ioctl+0x84/0xa0
> [c000200db64bbd40] c0000000003f8514 do_vfs_ioctl+0xd4/0xa00
> [c000200db64bbde0] c0000000003f8f04 SyS_ioctl+0xc4/0x130
> [c000200db64bbe30] c00000000000b184 system_call+0x58/0x6c
>
> When there is no room to send the I/O request, the cached room is refreshed
> by reading the memory mapped command room value from the AFU. The AFU
> register mapping is refreshed during a reset, creating a race condition
> that can lead to the Oops above.
>
> During a device reset, the AFU should not be unmapped until all the active
> send threads quiesce. An atomic counter, cmds_active, is currently used to
> track internal AFU commands and quiesce during reset. This same counter can
> also be used for the active send threads.
>
> Signed-off-by: Uma Krishnan <ukrishn@linux.vnet.ibm.com>
Acked-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com>
^ permalink raw reply
* Re: administrivia: mails containing HTML attachments
From: Stewart Smith @ 2018-05-16 14:46 UTC (permalink / raw)
To: Stephen Rothwell, ppc-dev
In-Reply-To: <20180516144829.2dbefb0b@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> I have decided that any email sent to the linuxppc-dev mailing list
> that contains an HTML attachment (or is just an HTML email) will be
> rejected. The vast majority of such mail are spam (and I have to spend
> time dropping them manually at the moment) and, I presume, anyone on
> this list is capable of sending no HTML email.
certainly one way to get those pesky IBM Verse users off. To be fair,
Documentation/process/email-clients.rst also warns them appropriately.
I fully support ditching HTML mail.
--
Stewart Smith
OPAL Architect, IBM.
^ permalink raw reply
* [PATCH v4 4/4] powerpc/kbuild: move -mprofile-kernel check to Kconfig
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
This eliminates the workaround that requires disabling
-mprofile-kernel by default in Kconfig.
[ Note: this depends on https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git kconfig-shell-v3 ]
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Since v3:
- Moved a stray hunk back to patch 3 where it belongs.
arch/powerpc/Kconfig | 16 +---------------
arch/powerpc/Makefile | 14 ++------------
2 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 512fcc177c87..af527f894f9b 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -460,23 +460,9 @@ config LD_HEAD_STUB_CATCH
If unsure, say "N".
-config DISABLE_MPROFILE_KERNEL
- bool "Disable use of mprofile-kernel for kernel tracing"
- depends on PPC64 && CPU_LITTLE_ENDIAN
- default y
- help
- Selecting this options disables use of the mprofile-kernel ABI for
- kernel tracing. That will cause options such as live patching
- (CONFIG_LIVEPATCH) which depend on CONFIG_DYNAMIC_FTRACE_WITH_REGS to
- be disabled also.
-
- If you have a toolchain which supports mprofile-kernel, then you can
- disable this. Otherwise leave it enabled. If you're not sure, say
- "Y".
-
config MPROFILE_KERNEL
depends on PPC64 && CPU_LITTLE_ENDIAN
- def_bool !DISABLE_MPROFILE_KERNEL
+ def_bool $(success $(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__)
config IOMMU_HELPER
def_bool PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 6faf1d6ad9dd..8f7a64fe7370 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -161,18 +161,8 @@ CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64
endif
ifdef CONFIG_MPROFILE_KERNEL
- ifeq ($(shell $(srctree)/arch/powerpc/tools/gcc-check-mprofile-kernel.sh $(CC) -I$(srctree)/include -D__KERNEL__),OK)
- CC_FLAGS_FTRACE := -pg -mprofile-kernel
- KBUILD_CPPFLAGS += -DCC_USING_MPROFILE_KERNEL
- else
- # If the user asked for mprofile-kernel but the toolchain doesn't
- # support it, emit a warning and deliberately break the build later
- # with mprofile-kernel-not-supported. We would prefer to make this an
- # error right here, but then the user would never be able to run
- # oldconfig to change their configuration.
- $(warning Compiler does not support mprofile-kernel, set CONFIG_DISABLE_MPROFILE_KERNEL)
- CC_FLAGS_FTRACE := -mprofile-kernel-not-supported
- endif
+ CC_FLAGS_FTRACE := -pg -mprofile-kernel
+ KBUILD_CPPFLAGS += -DCC_USING_MPROFILE_KERNEL
endif
CFLAGS-$(CONFIG_CELL_CPU) += $(call cc-option,-mcpu=cell)
--
2.17.0
^ permalink raw reply related
* [PATCH v4 3/4] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
The powerpc toolchain can compile combinations of 32/64 bit and
big/little endian, so it's convenient to consider, e.g.,
`CC -m64 -mbig-endian`
To be the C compiler for the purpose of invoking it to build target
artifacts. So overriding the the CC variable to include these flags
works for this purpose.
Unfortunately that is not compatible with the way the proposed new
Kconfig macro language implementation, which gets confused by the
the $(CC) environment variable changing.
After previous patches in this series, these flags can be carefully
passed in using the usual kbuild flags variables instead.
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
Since v3:
- Added 32/64 flags to recordmcount.pl invocation of the toolchain,
similarly to BE/LE. This fixes problems with toolchain default
target bitness != kernel target bitness. I kept Steven's ack
because it's much the same powerpc specific change, okay?
- Added a similar fix for mismatched toolchain default endianness
or bitness to the gcc-check-mprofile-kernel.sh script. This was
pulled in from patch 4 and improved (added comment and endianness
flags).
arch/powerpc/Makefile | 16 +++++++++-------
.../powerpc/tools/gcc-check-mprofile-kernel.sh | 12 ++++++++----
scripts/recordmcount.pl | 18 +++++++++++++++++-
3 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 167b26a0780c..6faf1d6ad9dd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -75,13 +75,15 @@ endif
endif
ifeq ($(CONFIG_CPU_LITTLE_ENDIAN),y)
-override LD += -EL
+KBUILD_CFLAGS += -mlittle-endian
+LDFLAGS += -EL
LDEMULATION := lppc
GNUTARGET := powerpcle
MULTIPLEWORD := -mno-multiple
KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
else
-override LD += -EB
+KBUILD_CFLAGS += $(call cc-option,-mbig-endian)
+LDFLAGS += -EB
LDEMULATION := ppc
GNUTARGET := powerpc
MULTIPLEWORD := -mmultiple
@@ -94,19 +96,19 @@ aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mabi=elfv1)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mabi=elfv2
endif
-cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
-cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
ifneq ($(cc-name),clang)
cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mno-strict-align
endif
+cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
+cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
aflags-$(CONFIG_CPU_BIG_ENDIAN) += $(call cc-option,-mbig-endian)
aflags-$(CONFIG_CPU_LITTLE_ENDIAN) += -mlittle-endian
ifeq ($(HAS_BIARCH),y)
-override AS += -a$(BITS)
-override LD += -m elf$(BITS)$(LDEMULATION)
-override CC += -m$(BITS)
+KBUILD_CFLAGS += -m$(BITS)
+KBUILD_AFLAGS += -m$(BITS) -Wl,-a$(BITS)
+LDFLAGS += -m elf$(BITS)$(LDEMULATION)
KBUILD_ARFLAGS += --target=elf$(BITS)-$(GNUTARGET)
endif
diff --git a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
index 061f8035bdbe..a7dd0e5d9f98 100755
--- a/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
+++ b/arch/powerpc/tools/gcc-check-mprofile-kernel.sh
@@ -7,17 +7,21 @@ set -o pipefail
# To debug, uncomment the following line
# set -x
+# -mprofile-kernel is only supported on 64le, so this should not be invoked
+# for other targets. Therefore we can pass in -m64 and -mlittle-endian
+# explicitly, to take care of toolchains defaulting to other targets.
+
# Test whether the compile option -mprofile-kernel exists and generates
# profiling code (ie. a call to _mcount()).
echo "int func() { return 0; }" | \
- $* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
- grep -q "_mcount"
+ $* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+ 2> /dev/null | grep -q "_mcount"
# Test whether the notrace attribute correctly suppresses calls to _mcount().
echo -e "#include <linux/compiler.h>\nnotrace int func() { return 0; }" | \
- $* -S -x c -O2 -p -mprofile-kernel - -o - 2> /dev/null | \
- grep -q "_mcount" && \
+ $* -m64 -mlittle-endian -S -x c -O2 -p -mprofile-kernel - -o - \
+ 2> /dev/null | grep -q "_mcount" && \
exit 1
echo "OK"
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 191eb949d52c..fe06e77c15eb 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -266,13 +266,29 @@ if ($arch eq "x86_64") {
$objcopy .= " -O elf32-sh-linux";
} elsif ($arch eq "powerpc") {
+ my $ldemulation;
+
$local_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)";
# See comment in the sparc64 section for why we use '\w'.
$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?\\w*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$";
+ if ($endian eq "big") {
+ $cc .= " -mbig-endian ";
+ $ld .= " -EB ";
+ $ldemulation = "ppc"
+ } else {
+ $cc .= " -mlittle-endian ";
+ $ld .= " -EL ";
+ $ldemulation = "lppc"
+ }
if ($bits == 64) {
- $type = ".quad";
+ $type = ".quad";
+ $cc .= " -m64 ";
+ $ld .= " -m elf64".$ldemulation." ";
+ } else {
+ $cc .= " -m32 ";
+ $ld .= " -m elf32".$ldemulation." ";
}
} elsif ($arch eq "arm") {
--
2.17.0
^ permalink raw reply related
* [PATCH v4 2/4] powerpc/kbuild: remove CROSS32 defines from top level powerpc Makefile
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
Switch VDSO32 build over to use CROSS32_COMPILE directly, and have
it pass in -m32 after the standard c_flags. This allows endianness
overrides to be removed and the endian and bitness flags moved into
standard flags variables.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/Makefile | 10 ----------
arch/powerpc/boot/Makefile | 16 +++++++++++-----
arch/powerpc/kernel/vdso32/Makefile | 15 +++++++++++----
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 15ca4bafad82..167b26a0780c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -17,14 +17,8 @@ HAS_BIARCH := $(call cc-option-yn, -m32)
# Set default 32 bits cross compilers for vdso and boot wrapper
CROSS32_COMPILE ?=
-CROSS32CC := $(CROSS32_COMPILE)gcc
-CROSS32AR := $(CROSS32_COMPILE)ar
-
ifeq ($(HAS_BIARCH),y)
ifeq ($(CROSS32_COMPILE),)
-CROSS32CC := $(CC) -m32
-KBUILD_ARFLAGS += --target=elf32-powerpc
-
ifdef CONFIG_PPC32
# These options will be overridden by any -mcpu option that the CPU
# or platform code sets later on the command line, but they are needed
@@ -33,13 +27,9 @@ ifdef CONFIG_PPC32
KBUILD_CFLAGS += -mcpu=powerpc
KBUILD_AFLAGS += -mcpu=powerpc
endif
-
endif
endif
-
-export CROSS32CC CROSS32AR
-
ifeq ($(CROSS_COMPILE),)
KBUILD_DEFCONFIG := $(shell uname -m)_defconfig
else
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 26d5d2a5b8e9..49767e06202c 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -23,19 +23,23 @@ all: $(obj)/zImage
compress-$(CONFIG_KERNEL_GZIP) := CONFIG_KERNEL_GZIP
compress-$(CONFIG_KERNEL_XZ) := CONFIG_KERNEL_XZ
+ifdef CROSS32_COMPILE
+ BOOTCC := $(CROSS32_COMPILE)gcc
+ BOOTAR := $(CROSS32_COMPILE)ar
+else
+ BOOTCC := $(CC)
+ BOOTAR := $(AR)
+endif
+
BOOTCFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -Os -msoft-float -pipe \
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc \
-D$(compress-y)
-BOOTCC := $(CC)
ifdef CONFIG_PPC64_BOOT_WRAPPER
BOOTCFLAGS += -m64
else
BOOTCFLAGS += -m32
-ifdef CROSS32_COMPILE
- BOOTCC := $(CROSS32_COMPILE)gcc
-endif
endif
BOOTCFLAGS += -isystem $(shell $(BOOTCC) -print-file-name=include)
@@ -49,6 +53,8 @@ endif
BOOTAFLAGS := -D__ASSEMBLY__ $(BOOTCFLAGS) -traditional -nostdinc
+BOOTARFLAGS := -cr$(KBUILD_ARFLAGS)
+
ifdef CONFIG_DEBUG_INFO
BOOTCFLAGS += -g
endif
@@ -202,7 +208,7 @@ quiet_cmd_bootas = BOOTAS $@
cmd_bootas = $(BOOTCC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $<
quiet_cmd_bootar = BOOTAR $@
- cmd_bootar = $(CROSS32AR) -cr$(KBUILD_ARFLAGS) $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
+ cmd_bootar = $(BOOTAR) $(BOOTARFLAGS) $@.$$$$ $(filter-out FORCE,$^); mv $@.$$$$ $@
$(obj-libfdt): $(obj)/%.o: $(srctree)/scripts/dtc/libfdt/%.c FORCE
$(call if_changed_dep,bootcc)
diff --git a/arch/powerpc/kernel/vdso32/Makefile b/arch/powerpc/kernel/vdso32/Makefile
index b8c434d1d459..50112d4473bb 100644
--- a/arch/powerpc/kernel/vdso32/Makefile
+++ b/arch/powerpc/kernel/vdso32/Makefile
@@ -8,8 +8,15 @@ obj-vdso32 = sigtramp.o gettimeofday.o datapage.o cacheflush.o note.o \
# Build rules
-ifeq ($(CONFIG_PPC32),y)
-CROSS32CC := $(CC)
+ifdef CROSS32_COMPILE
+ VDSOCC := $(CROSS32_COMPILE)gcc
+else
+ VDSOCC := $(CC)
+endif
+
+CC32FLAGS :=
+ifdef CONFIG_PPC64
+CC32FLAGS += -m32
endif
targets := $(obj-vdso32) vdso32.so vdso32.so.dbg
@@ -45,9 +52,9 @@ $(obj-vdso32): %.o: %.S FORCE
# actual build commands
quiet_cmd_vdso32ld = VDSO32L $@
- cmd_vdso32ld = $(CROSS32CC) $(c_flags) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^)
+ cmd_vdso32ld = $(VDSOCC) $(c_flags) $(CC32FLAGS) -o $@ -Wl,-T$(filter %.lds,$^) $(filter %.o,$^)
quiet_cmd_vdso32as = VDSO32A $@
- cmd_vdso32as = $(CROSS32CC) $(a_flags) -c -o $@ $<
+ cmd_vdso32as = $(VDSOCC) $(a_flags) $(CC32FLAGS) -c -o $@ $<
# install commands for the unstripped file
quiet_cmd_vdso_install = INSTALL $@
--
2.17.0
^ permalink raw reply related
* [PATCH v4 1/4] powerpc/kbuild: set default generic machine type for 32-bit compile
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
In-Reply-To: <20180516141458.18996-1-npiggin@gmail.com>
Some 64-bit toolchains uses the wrong ISA variant for compiling 32-bit
kernels, even with -m32. Debian's powerpc64le is one such case, and
that is because it is built with --with-cpu=power8.
So when cross compiling a 32-bit kernel with a 64-bit toolchain, set
-mcpu=powerpc initially, which is the generic 32-bit powerpc machine
type and scheduling model. CPU and platform code can override this
with subsequent -mcpu flags if necessary.
This is not done for 32-bit toolchains otherwise it would override
their defaults, which are presumably set appropriately for the
environment (moreso than a 64-bit cross compiler).
This fixes a lot of build failures due to incompatible assembly when
compiling 32-bit kernel with th Debian powerpc64le 64-bit toolchain.
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/Makefile | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 95813df90801..15ca4bafad82 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -24,9 +24,20 @@ ifeq ($(HAS_BIARCH),y)
ifeq ($(CROSS32_COMPILE),)
CROSS32CC := $(CC) -m32
KBUILD_ARFLAGS += --target=elf32-powerpc
+
+ifdef CONFIG_PPC32
+# These options will be overridden by any -mcpu option that the CPU
+# or platform code sets later on the command line, but they are needed
+# to set a sane 32-bit cpu target for the 64-bit cross compiler which
+# may default to the wrong ISA.
+KBUILD_CFLAGS += -mcpu=powerpc
+KBUILD_AFLAGS += -mcpu=powerpc
+endif
+
endif
endif
+
export CROSS32CC CROSS32AR
ifeq ($(CROSS_COMPILE),)
--
2.17.0
^ permalink raw reply related
* [PATCH v4 0/4] powerpc patches for new Kconfig language
From: Nicholas Piggin @ 2018-05-16 14:14 UTC (permalink / raw)
To: linux-kbuild
Cc: Nicholas Piggin, linuxppc-dev, Masahiro Yamada,
Segher Boessenkool
This series of patches improves th powerpc kbuild system. The
motivation was to to be compatible with the new Kconfig scripting
language that Yamada-san has proposed here:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/?h=kconfig-shell-v3
I have tested on top of that tree and powerpc now builds there.
I think patches 1-3 are improvements to the build system even before
kconfig-shell, so they could be merged ahead of it in the powerpc
tree.
Patch 4 takes advatage of a new feature of the kconfig-shell work to
improve powerpc kconfig, so that should instead be merged with the
kbuild tree with an ack from powerpc, after patches 1-3 are merged.
v4 just brings some build fixes to patch 3 (including a change from
patch 4 that belonged in patch 3), and improvemets to changelogs.
Thanks,
Nick
Nicholas Piggin (4):
powerpc/kbuild: set default generic machine type for 32-bit compile
powerpc/kbuild: remove CROSS32 defines from top level powerpc Makefile
powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS
powerpc/kbuild: move -mprofile-kernel check to Kconfig
arch/powerpc/Kconfig | 16 +------
arch/powerpc/Makefile | 45 ++++++++-----------
arch/powerpc/boot/Makefile | 16 ++++---
arch/powerpc/kernel/vdso32/Makefile | 15 +++++--
.../tools/gcc-check-mprofile-kernel.sh | 12 +++--
scripts/recordmcount.pl | 18 +++++++-
6 files changed, 67 insertions(+), 55 deletions(-)
--
2.17.0
^ permalink raw reply
* Re: [kernel, v3] powerpc/ioda: Use ibm, supported-tce-sizes for IOMMU page size mask
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy, David Gibson
In-Reply-To: <20180514093922.27179-1-aik@ozlabs.ru>
On Mon, 2018-05-14 at 09:39:22 UTC, Alexey Kardashevskiy wrote:
> At the moment we assume that IODA2 and newer PHBs can always do 4K/64K/16M
> IOMMU pages, however this is not the case for POWER9 and now skiboot
> advertises the supported sizes via the device so we use that instead
> of hard coding the mask.
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/7ef73cd39b4e2829ee88c06f938bc7
cheers
^ permalink raw reply
* Re: selftests/powerpc: fix exec benchmark
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180512033525.18762-1-npiggin@gmail.com>
On Sat, 2018-05-12 at 03:35:24 UTC, Nicholas Piggin wrote:
> The exec_target binary could segfault calling _exit(2) because r13
> is not set up properly (and libc looks at that when performing a
> syscall). Call SYS_exit using syscall(2) which doesn't seem to
> have this problem.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c906d2c74e0bb9059fbf43e21f8a96
cheers
^ permalink raw reply
* Re: macintosh/windfarm: fix spelling mistake: "ttarged" -> "ttarget"
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Colin King, Benjamin Herrenschmidt, linuxppc-dev
Cc: kernel-janitors, linux-kernel
In-Reply-To: <20180510155439.16582-1-colin.king@canonical.com>
On Thu, 2018-05-10 at 15:54:39 UTC, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake in debug messages of a structure
> field name
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/942cc40ae4354fee1e97137346434a
cheers
^ permalink raw reply
* Re: powerpc/powernv: Fix memtrace build when NUMA=n
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: rashmica.g, anton
In-Reply-To: <20180510130913.23931-1-mpe@ellerman.id.au>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Thu, 2018-05-10 at 13:09:13 UTC, Michael Ellerman wrote:
> Currently memtrace doesn't build if NUMA=n:
>
> In function ‘memtrace_alloc_node’:
> arch/powerpc/platforms/powernv/memtrace.c:134:6:
> error: the address of ‘contig_page_data’ will always evaluate as ‘true’
> if (!NODE_DATA(nid) || !node_spanned_pages(nid))
> ^
>
> This is because for NUMA=n NODE_DATA(nid) points to an always
> allocated structure, contig_page_data.
>
> But even in the NUMA=y case memtrace_alloc_node() is only called for
> online nodes, and we should always have a NODE_DATA() allocated for an
> online node. So remove the (hopefully) overly paranoid check, which
> also means we can build when NUMA=n.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/8ccb442dec0ab53eefb5a607e405f7
cheers
^ permalink raw reply
* Re: [1/3] powerpc/prom: Drop support for old FDT versions
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180509134229.26278-1-mpe@ellerman.id.au>
On Wed, 2018-05-09 at 13:42:27 UTC, Michael Ellerman wrote:
> In commit e6a6928c3ea1 ("of/fdt: Convert FDT functions to use
> libfdt") (Apr 2014), the generic flat device tree code dropped support
> for flat device tree's older than version 0x10 (16).
>
> We still have code in our CPU scanning to cope with flat device tree
> versions earlier than 2, which can now never trigger, so drop it.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/89c190627257a38d5e4d7cb3e5382f
cheers
^ permalink raw reply
* Re: [v2] powerpc: platform: cell: spufs: Change return type to vm_fault_t
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Souptick Joarder, willy, jk, arnd, benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20180420173239.GA24560@jordon-HP-15-Notebook-PC>
On Fri, 2018-04-20 at 17:32:39 UTC, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Reference id -> 1c8f422059ae ("mm: change return type to
> vm_fault_t")
>
> We are fixing a minor bug, that the error from vm_insert_
> pfn() was being ignored and the effect of this is likely
> to be only felt in OOM situations.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e807f02c5c364c5a7315b50efdbc10
cheers
^ permalink raw reply
* Re: [2/5] powerpc/lib: Fix feature fixup test of external branch
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: aik, paulus
In-Reply-To: <20180416143905.2716-2-mpe@ellerman.id.au>
On Mon, 2018-04-16 at 14:39:02 UTC, Michael Ellerman wrote:
> The expected case for this test was wrong, the source of the alternate
> code sequence is:
>
> FTR_SECTION_ELSE
> 2: or 2,2,2
> PPC_LCMPI r3,1
> beq 3f
> blt 2b
> b 3f
> b 1b
> ALT_FTR_SECTION_END(0, 1)
> 3: or 1,1,1
> or 2,2,2
> 4: or 3,3,3
>
> So when it's patched the '3' label should still be on the 'or 1,1,1',
> and the 4 label is irrelevant and can be removed.
>
> Fixes: 362e7701fd18 ("powerpc: Add self-tests of the feature fixup code")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Patches 2-5 applied to powerpc next.
https://git.kernel.org/powerpc/c/32810d91325ec76b8ef4df463f8a0e
cheers
^ permalink raw reply
* Re: [V1, 01/11] powerpc/mm/book3s64: Move book3s64 code to pgtable-book3s64
From: Michael Ellerman @ 2018-05-16 13:38 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20180416112724.9677-3-aneesh.kumar@linux.ibm.com>
On Mon, 2018-04-16 at 11:27:14 UTC, "Aneesh Kumar K.V" wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>
> Only code movement and avoid #ifdef.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/59879d542a8e880391863d82cddf38
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv: Add queue mechanism for early messages
From: Michael Ellerman @ 2018-05-16 13:35 UTC (permalink / raw)
To: Deb McLemore, linuxppc-dev; +Cc: Deb McLemore, jk
In-Reply-To: <1511989553-16198-1-git-send-email-debmc@linux.vnet.ibm.com>
Deb McLemore <debmc@linux.vnet.ibm.com> writes:
> Problem being solved is when issuing a BMC soft poweroff during IPL,
> the poweroff was being lost so the machine would not poweroff.
>
> Opal messages were being received before the opal-power code
> registered its notifiers.
>
> Alternatives discussed (option #3 was chosen):
>
> 1 - Have opal_message_init() explicitly call opal_power_control_init()
> before it dequeues any OPAL messages (i.e. before we register the
> opal-msg IRQ handler).
>
> 2 - Introduce concept of critical message types and when we register
> handlers we track which message types have a registered handler,
> then defer the opal-msg IRQ registration until we have a handler
> registered for all the critical types.
>
> 3 - Buffering messages, if we receive a message and do not yet
> have a handler for that type, store the message and replay when
> a handler for that type is registered.
>
> Signed-off-by: Deb McLemore <debmc@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/opal.c | 83 ++++++++++++++++++++++++++++++++---
> 1 file changed, 78 insertions(+), 5 deletions(-)
Hi Deb,
Sorry for the delay (!) on this one.
A couple more comments ...
> diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
> index 65c79ec..46d7604 100644
> --- a/arch/powerpc/platforms/powernv/opal.c
> +++ b/arch/powerpc/platforms/powernv/opal.c
> @@ -238,14 +288,25 @@ machine_early_initcall(powernv, opal_register_exception_handlers);
> int opal_message_notifier_register(enum opal_msg_type msg_type,
> struct notifier_block *nb)
> {
> + int ret;
> +
> if (!nb || msg_type >= OPAL_MSG_TYPE_MAX) {
> pr_warning("%s: Invalid arguments, msg_type:%d\n",
> __func__, msg_type);
> return -EINVAL;
> }
We still want to take the msg_list_lock around the registration, ie.
from here to the end of the function.
> - return atomic_notifier_chain_register(
> - &opal_msg_notifier_head[msg_type], nb);
> + ret = atomic_notifier_chain_register(
> + &opal_msg_notifier_head[msg_type], nb);
> +
> + if (ret)
> + return ret;
Otherwise a message that arrives here will be delivered before any
queued messages, which might be a problem.
> +
> + /* Replay any queued messages that came in */
> + /* prior to the notifier chain registration */
> + dequeue_replay_msg(msg_type);
> +
> + return 0;
> }
> EXPORT_SYMBOL_GPL(opal_message_notifier_register);
>
> @@ -259,9 +320,21 @@ EXPORT_SYMBOL_GPL(opal_message_notifier_unregister);
>
> static void opal_message_do_notify(uint32_t msg_type, void *msg)
> {
> - /* notify subscribers */
> - atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type],
> - msg_type, msg);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&msg_list_lock, flags);
> +
> + if (opal_msg_notifier_head[msg_type].head != NULL) {
> + /* notify subscribers */
> + atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type],
> + msg_type, msg);
> + } else {
> + /* Queue up the msg since no notifiers have */
> + /* registered yet for this msg_type */
> + queue_replay_msg(msg);
> + }
> +
> + spin_unlock_irqrestore(&msg_list_lock, flags);
I don't think it's actually likely to be a problem, but it would be nice
if we didn't have to hold the lock while calling the notifier in the
general case.
I think we can do that with eg:
bool queued = false;
spin_lock_irqsave(&msg_list_lock, flags);
if (opal_msg_notifier_head[msg_type].head == NULL) {
/*
* Queue up the msg since no notifiers have registered
* yet for this msg_type.
*/
queue_replay_msg(msg);
queued = true;
}
spin_unlock_irqrestore(&msg_list_lock, flags);
if (queued)
return;
/* notify subscribers */
atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type], msg_type, msg);
cheers
^ permalink raw reply
* [PATCH] cpuidle/powernv : init all present cpus for deep states
From: Akshay Adiga @ 2018-05-16 12:02 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev; +Cc: npiggin, mpe, ego, Akshay Adiga
Init all present cpus for deep states instead of "all possible" cpus.
Init fails if the possible cpu is gaurded. Resulting in making only
non-deep states available for cpuidle/hotplug.
Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/idle.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 1f12ab1..1c5d067 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -79,7 +79,7 @@ static int pnv_save_sprs_for_deep_states(void)
uint64_t msr_val = MSR_IDLE;
uint64_t psscr_val = pnv_deepest_stop_psscr_val;
- for_each_possible_cpu(cpu) {
+ for_each_present_cpu(cpu) {
uint64_t pir = get_hard_smp_processor_id(cpu);
uint64_t hsprg0_val = (uint64_t)paca_ptrs[cpu];
@@ -814,7 +814,7 @@ static int __init pnv_init_idle_states(void)
int cpu;
pr_info("powernv: idle: Saving PACA pointers of all CPUs in their thread sibling PACA\n");
- for_each_possible_cpu(cpu) {
+ for_each_present_cpu(cpu) {
int base_cpu = cpu_first_thread_sibling(cpu);
int idx = cpu_thread_in_core(cpu);
int i;
--
2.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox