Re: [PATCH v2 3/5] kbuild: call cc-option with the current set of KBUILD_CFLAGS

2018-05-10 14:16 GMT+09:00 Nicholas Piggin : > In some cases, the options that gcc will accept depend on options it > has already been given. For example -m32 / -m64 and -mbig-endian / > -mlittle-endian can have this affect. Is cc-option not working for you? > Passing in

Re: [PATCH] powerpc/kbuild: set generic machine type for compile with 64-bit toolchain

On Thu, 10 May 2018 10:26:37 +1000 Nicholas Piggin wrote: > The 64-bit toolchain uses the wrong ISA variant for compiling 32-bit > kernels, eve with -m32. Set -mcpu=powerpc which is the generic 32-bit > powerpc machine type and scheduling model. 32-bit platforms and CPUs > can

[PATCH v2 5/5] powerpc/kbuild: move -mprofile-kernel check to Kconfig

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 --- arch/powerpc/Kconfig

[PATCH v2 4/5] powerpc/kbuild: Use flags variables rather than overriding LD/CC/AS

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 thse flags works for this

[PATCH v2 3/5] kbuild: call cc-option with the current set of KBUILD_CFLAGS

In some cases, the options that gcc will accept depend on options it has already been given. For example -m32 / -m64 and -mbig-endian / -mlittle-endian can have this affect. Passing in KBUILD_CFLAGS to cc-option allows an architecture to set such basic machine types at the beginning, rather than

[PATCH v2 2/5] powerpc/kbuild: remove CROSS32 defines from top level powerpc Makefile

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

[PATCH v2 1/5] powerpc/kbuild: set default generic machine type for 32-bit compile

The 64-bit toolchain uses the wrong ISA variant for compiling 32-bit kernels, eve with -m32. Set -mcpu=powerpc which is the generic 32-bit powerpc machine type and scheduling model. 32-bit platforms and CPUs can override this with -mcpu= options that come later on the command line. This fixes a

[PATCH v2 0/5] kbuild and powerpc patches for new Kconfig language

I came back to these patches and I think I have solved the remaining problems -- it now builds with 64-bit big and little endian (using a le toolchain), and also 32-bit big using 64le toolchain. There might be some build failures still left, but it seems to be in much better shape now. Reviews

Re: powerpc/pseries: Fix CONFIG_NUMA=n build

On Wed, 2018-05-09 at 14:58:18 UTC, Michael Ellerman wrote: > The build is failing with CONFIG_NUMA=n and some compiler versions: > > arch/powerpc/platforms/pseries/hotplug-cpu.o: In function > `dlpar_online_cpu': > hotplug-cpu.c:(.text+0x12c): undefined reference to `timed_topology_update'

Re: [PATCH] powerpc/kbuild: set generic machine type for compile with 64-bit toolchain

Bad title, should be set generic machine type for 32-bit compile with 64-bit toolchain On Thu, 10 May 2018 10:26:37 +1000 Nicholas Piggin wrote: > The 64-bit toolchain uses the wrong ISA variant for compiling 32-bit > kernels, eve with -m32. Set -mcpu=powerpc which is the

Re: [PATCH 2/2] powerpc/64: change softe to irqmask in show_regs and xmon

On Thu, May 10, 2018 at 11:04 AM, Nicholas Piggin wrote: > When the soft enabled flag was changed to a soft disable mask, xmon > and register dump code was not updated to reflect that, which is > confusing ('SOFTE: 1' previously meant interrupts were soft enabled, > currently

[PATCH 2/2] powerpc/64: change softe to irqmask in show_regs and xmon

When the soft enabled flag was changed to a soft disable mask, xmon and register dump code was not updated to reflect that, which is confusing ('SOFTE: 1' previously meant interrupts were soft enabled, currently it means the opposite, the general interrupt type has been disabled). Fix this by

[PATCH 1/2] powerpc/pmu/fsl: fix is_nmi test for irq mask change

When soft enabled was changed to irq disabled mask, this test missed being converted (although the equivalent book3s test was converted). The PMU drivers consider it an NMI when they take a PMI while general interrupts are disabled. This change restores that behaviour. Fixes: 01417c6cc7

Re: linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

Stephen Rothwell writes: > Hi all, > > Today's linux-next merge of the powerpc tree got a conflict in: > > arch/powerpc/include/asm/ftrace.h > > between commit: > > edf6a2dfe388 ("powerpc/trace/syscalls: Update syscall name matching logic > to account for ppc_

[PATCH] powerpc/kbuild: set generic machine type for compile with 64-bit toolchain

The 64-bit toolchain uses the wrong ISA variant for compiling 32-bit kernels, eve with -m32. Set -mcpu=powerpc which is the generic 32-bit powerpc machine type and scheduling model. 32-bit platforms and CPUs can override this with -mcpu= options that come later on the command line. This fixes a

linux-next: manual merge of the powerpc tree with the powerpc-fixes tree

Hi all, Today's linux-next merge of the powerpc tree got a conflict in: arch/powerpc/include/asm/ftrace.h between commit: edf6a2dfe388 ("powerpc/trace/syscalls: Update syscall name matching logic to account for ppc_ prefix") from the powerpc-fixes tree and commit: c3e59d778403

[powerpc:merge 138/138] arch/powerpc/kernel/setup_64.c:354:2: error: implicit declaration of function 'this_cpu_enable_ftrace'; did you mean 'preempt_enable_notrace'?

tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge head: 900be8ab1549359ba980cfb042a043128204a963 commit: 900be8ab1549359ba980cfb042a043128204a963 [138/138] Automatic merge of branches 'master', 'next' and 'fixes' into merge config: powerpc-defconfig (attached as

Re: [PATCH 2/3] hwmon: (ibmpowernv): Add support to read 64 bit sensors

On Mon, May 07, 2018 at 03:55:37PM +0530, Shilpasri G Bhat wrote: > The firmware has supported for reading sensor values of size u32. > This patch adds support to use newer firmware functions which allows > to read the sensors of size u64. > > Signed-off-by: Shilpasri G Bhat

Re: [PATCH 3/3] hwmon: (ibmpowernv) Add energy sensors

On Mon, May 07, 2018 at 03:55:38PM +0530, Shilpasri G Bhat wrote: > This patch exports the accumulated power numbers of each power > sensor maintained by OCC. > > Signed-off-by: Shilpasri G Bhat Acked-by: Guenter Roeck > --- >

Re: make a few block drivers highmem safe

On 5/9/18 7:59 AM, Christoph Hellwig wrote: > Hi all, > > this series converts a few random block drivers to be highmem safe, > in preparation of eventually getting rid of the block layer bounce > buffering support. Series looks good to me. -- Jens Axboe

[RFC v3 3/3] powerpc migration/memory: Associativity & memory updates

powerpc migration/memory: This patch adds more recognition for changes to the associativity of memory blocks described by the device-tree properties and updates local and general kernel data structures to reflect those changes. These differences may include: * Evaluating 'ibm,dynamic-memory'

[RFC v3 2/3] powerpc migration/cpu: Associativity & cpu changes

powerpc migration/cpu: Now apply changes to the associativity of cpus for the topology of LPARS in Post Migration events. Recognize more changes to the associativity of memory blocks described by the 'cpu' properties when processing the topology of LPARS in Post Migration events. Previous

[RFC v3 1/3] powerpc migration/drmem: Modify DRMEM code to export more features

powerpc migration/drmem: Export many of the functions of DRMEM to parse "ibm,dynamic-memory" and "ibm,dynamic-memory-v2" during hotplug operations and for Post Migration events. Also modify the DRMEM initialization code to allow it to, * Be called after system initialization * Provide a separate

[RFC v3 0/3] powerpc/hotplug: Fix affinity assoc for LPAR migration

The migration of LPARs across Power systems affects many attributes including that of the associativity of memory blocks and CPUs. The patches in this set execute when a system is coming up fresh upon a migration target. They are intended to, * Recognize changes to the associativity of memory

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

On Wed, 9 May 2018 08:46:08 -0700 Dave Hansen wrote: > On 05/09/2018 08:43 AM, Michal Suchánek wrote: > > It seems it is somehow assumed this is key 0 but I did not find it > > documented anywhere nor did I notice an interface for determining > > the default key. > >

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

On 05/09/2018 08:43 AM, Michal Suchánek wrote: > It seems it is somehow assumed this is key 0 but I did not find it > documented anywhere nor did I notice an interface for determining the > default key. Does the manpage not count as documentation? :) "pkey 0 is used as the default key"

Re: [PATCH v3] powerpc, pkey: make protection key 0 less special

On Fri, 4 May 2018 12:22:58 -0700 Ram Pai wrote: > Applications need the ability to associate an address-range with some > key and latter revert to its initial default key. Pkey-0 comes close > to providing this function but falls short, because the current > implementation

Re: [PATCH 2/7] DAC960: don't use block layer bounce buffers

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: [PATCH 1/7] mtip32xx: don't use block layer bounce buffers

Looks good, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham

Re: [1/2] powerpc/trace elfv1: Update syscall name matching logic

On Fri, 2018-05-04 at 13:14:24 UTC, "Naveen N. Rao" wrote: > On powerpc64 ABIv1, we are enabling syscall tracing for only ~20 > syscalls. This is due to commit e145242ea0df6 ("syscalls/core, > syscalls/x86: Clean up syscall stub naming convention") which has > changed the syscall entry wrapper

Re: powerpc/64: Remove unused paca->soft_enabled

On Wed, 2018-05-02 at 06:57:54 UTC, Michael Ellerman wrote: > In commit 4e26bc4a4ed6 ("powerpc/64: Rename soft_enabled to > irq_soft_mask") we renamed paca->soft_enabled. But then in commit > 8e0b634b1327 ("powerpc/64s: Do not allocate lppaca if we are not > virtualized") we added it back. Oops.

[PATCH] powerpc/pseries: Fix CONFIG_NUMA=n build

The build is failing with CONFIG_NUMA=n and some compiler versions: arch/powerpc/platforms/pseries/hotplug-cpu.o: In function `dlpar_online_cpu': hotplug-cpu.c:(.text+0x12c): undefined reference to `timed_topology_update' arch/powerpc/platforms/pseries/hotplug-cpu.o: In function

Re: [PATCH 13/13] powerpc/eeh: Refactor report functions

Sam Bobroff writes: > On Thu, May 03, 2018 at 11:27:12PM +1000, Michael Ellerman wrote: >> Sam Bobroff writes: >> > diff --git a/arch/powerpc/kernel/eeh_driver.c >> > b/arch/powerpc/kernel/eeh_driver.c >> > index eb4feee81ff4..1c4336dcf9f5 100644

Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics

On Tue, May 8, 2018 at 5:40 AM Florian Weimer wrote: > On 05/08/2018 04:49 AM, Andy Lutomirski wrote: > > On Mon, May 7, 2018 at 2:48 AM Florian Weimer wrote: > > > >> On 05/03/2018 06:05 AM, Andy Lutomirski wrote: > >>> On Wed, May 2, 2018 at 7:11 PM Ram

make a few block drivers highmem safe

Hi all, this series converts a few random block drivers to be highmem safe, in preparation of eventually getting rid of the block layer bounce buffering support.

[PATCH 7/7] ps3disk: handle highmem pages

The ps3disk driver already kmaps all pages when copying from/to the internal bounce buffer, so it can accept highmem pages just fine. Signed-off-by: Christoph Hellwig --- drivers/block/ps3disk.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/block/ps3disk.c

[PATCH 6/7] jsflash: handle highmem pages

Just kmap the bio single page payload before processing it. (and yes, now highmem on sparc32 anyway, but kmap_(un)map atomic are nops, so this gives the right example) Signed-off-by: Christoph Hellwig --- drivers/sbus/char/jsflash.c | 6 -- 1 file changed, 4 insertions(+), 2

[PATCH 5/7] aoe: handle highmem pages

Use kmap_atomic when copying out of a bio_vec. Signed-off-by: Christoph Hellwig --- drivers/block/aoe/aoeblk.c | 1 - drivers/block/aoe/aoecmd.c | 3 ++- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c index

[PATCH 4/7] mtd_blkdevs: handle highmem pages

Just kmap the single payload page before passing it on to the FTL. Signed-off-by: Christoph Hellwig --- drivers/mtd/mtd_blkdevs.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-) diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c index

[PATCH 3/7] memstick: don't call blk_queue_bounce_limit

All in-tree host drivers set up a proper dma mask and use the dma-mapping helpers. This means they will be able to deal with any address that we are throwing at them. Signed-off-by: Christoph Hellwig --- drivers/memstick/core/ms_block.c| 5 -

[PATCH 2/7] DAC960: don't use block layer bounce buffers

DAC960 just sets the block bounce limit to the dma mask, which means that the iommu or swiotlb already take care of the bounce buffering, and the block bouncing can be removed. Signed-off-by: Christoph Hellwig --- drivers/block/DAC960.c | 9 ++--- drivers/block/DAC960.h | 1 -

[PATCH 1/7] mtip32xx: don't use block layer bounce buffers

mtip32xx just sets the block bounce limit to the dma mask, which means that the iommu or swiotlb already take care of the bounce buffering, and the block bouncing can be removed. Signed-off-by: Christoph Hellwig --- drivers/block/mtip32xx/mtip32xx.c | 1 - 1 file changed, 1

[PATCH 3/3] powerpc/prom: Clean up local variables in early_init_dt_scan_cpus()

This is cosmetic, but the current arrangement is hell ugly, so clean it up. Signed-off-by: Michael Ellerman --- arch/powerpc/kernel/prom.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/powerpc/kernel/prom.c

[PATCH 2/3] powerpc/prom: Save the boot CPU hardware id in a local

In early_init_dt_scan_cpus() we find the boot CPU, and get it's hardware CPU number. Currently we do that by using the thread number and doing be32_to_cpu(instserv[i]) three times. The endian flips are not very efficient, but the main concern is just that it's ugly to do the same flip in three

[PATCH 1/3] powerpc/prom: Drop support for old FDT versions

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

Re: [PATCH kernel v2] powerpc/ioda: Use ibm, supported-tce-sizes for IOMMU page size mask

Alexey Kardashevskiy writes: > 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. > >

[PATCH v2 4/4] powerpc: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selected

This requires further changes to linker script to KEEP some tables and wildcard compiler generated sections into the right place. This includes pp32 modifications from Christophe Leroy. When compiling powernv_defconfig with this option, the resulting kernel is almost 400kB smaller (and still

[PATCH v2 3/4] kbuild: Allow LD_DEAD_CODE_DATA_ELIMINATION to be selectable if enabled

Architectures that are capable can select HAVE_LD_DEAD_CODE_DATA_ELIMINATION to enable selection of that option (as an EXPERT kernel option). Signed-off-by: Nicholas Piggin --- arch/Kconfig | 15 --- init/Kconfig | 27 +++ 2 files changed,

[PATCH v2 2/4] kbuild: LD_DEAD_CODE_DATA_ELIMINATION no -ffunction-sections/-fdata-sections for module build

Modules do not tend to cope with -ffunction-sections, even though they do not link with -gc-sections. It may be possible for unused symbols to be trimmed from modules, but in general that would take much more work in architecture module linker scripts. For now, enable these only for kernel build.

[PATCH v2 1/4] kbuild: Fix asm-generic/vmlinux.lds.h for LD_DEAD_CODE_DATA_ELIMINATION

KEEP more tables, and add the function/data section wildcard to more section selections. This is a little ad-hoc at the moment, but kernel code should be moved to consistently use .text..x (note: double dots) for explicit sections and all references to it in the linker script can be made with

[PATCH v2 0/4] LD_DEAD_CODE_DATA_ELIMINATION fixes and enabling for powerpc

v2 changes only patch 4, updates the changelog with ppc32 numbers and Tested-by tags, and also use TEXT_MAIN in the linker script as Christophe suggested. Thanks, Nick Nicholas Piggin (4): kbuild: Fix asm-generic/vmlinux.lds.h for LD_DEAD_CODE_DATA_ELIMINATION kbuild:

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

On Wed, 09 May 2018 18:31:55 +1000 Benjamin Herrenschmidt wrote: > On Wed, 2018-05-09 at 16:56 +1000, Nicholas Piggin wrote: > > When a single-threaded process has a non-local mm_cpumask and requires > > a full PID tlbie invalidation, use that as an opportunity to reset the > >

Re: [PATCH 1/2] powerpc/64s/radix: do not flush TLB when relaxing access

On Wed, 9 May 2018 18:27:07 +1000 Balbir Singh wrote: > On Wed, May 9, 2018 at 5:43 PM, Nicholas Piggin wrote: > > On Wed, 9 May 2018 17:07:47 +1000 > > Balbir Singh wrote: > > > >> On Wed, May 9, 2018 at 4:51 PM, Nicholas

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

On Wed, 9 May 2018 18:23:48 +1000 Balbir Singh wrote: > On Wed, May 9, 2018 at 4:56 PM, Nicholas Piggin wrote: > > When a single-threaded process has a non-local mm_cpumask and requires > > a full PID tlbie invalidation, use that as an opportunity to

Re: [PATCH v3] ppc64le livepatch: implement reliable stacktrace for newer consistency models

On Wed, May 09, 2018 at 11:41:09AM +1000, Michael Ellerman wrote: > Josh Poimboeuf writes: > > > Generally we refer to it as "the consistency model". [...] > > We use "powerpc" as the prefix. > > So I've used: > > powerpc/livepatch: Implement reliable stack tracing for

Re: [PATCH] powerpc/pseries: hcall_exit tracepoint retval should be signed

On 05/07/2018 06:33 PM, Michael Ellerman wrote: > The hcall_exit() tracepoint has retval defined as unsigned long. That > leads to humours results like: > > bash-3686 [009] d..2 854.134094: hcall_entry: opcode=24 > bash-3686 [009] d..2 854.134095: hcall_exit: opcode=24 >

[PATCH] crypto: nx: fix spelling mistake: "seqeunce" -> "sequence"

From: Colin Ian King Trivial fix to spelling mistake in CSB_ERR error message text Signed-off-by: Colin Ian King --- drivers/crypto/nx/nx-842-powernv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

On Wed, 2018-05-09 at 16:56 +1000, Nicholas Piggin wrote: > When a single-threaded process has a non-local mm_cpumask and requires > a full PID tlbie invalidation, use that as an opportunity to reset the > cpumask back to the current CPU we're running on. > > No other thread can concurrently

Re: [PATCH 1/2] powerpc/64s/radix: do not flush TLB when relaxing access

On Wed, May 9, 2018 at 5:43 PM, Nicholas Piggin wrote: > On Wed, 9 May 2018 17:07:47 +1000 > Balbir Singh wrote: > >> On Wed, May 9, 2018 at 4:51 PM, Nicholas Piggin wrote: >> > Radix flushes the TLB when updating ptes to increase

Re: [PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

On Wed, May 9, 2018 at 4:56 PM, Nicholas Piggin wrote: > When a single-threaded process has a non-local mm_cpumask and requires > a full PID tlbie invalidation, use that as an opportunity to reset the > cpumask back to the current CPU we're running on. > > No other thread can

Re: [PATCH 1/2] powerpc/64s/radix: do not flush TLB when relaxing access

On Wed, 9 May 2018 17:07:47 +1000 Balbir Singh wrote: > On Wed, May 9, 2018 at 4:51 PM, Nicholas Piggin wrote: > > Radix flushes the TLB when updating ptes to increase permissiveness > > of protection (increase access authority). Book3S does not require

Re: [PATCH 1/2] powerpc/64s/radix: do not flush TLB when relaxing access

On Wed, May 9, 2018 at 4:51 PM, Nicholas Piggin wrote: > Radix flushes the TLB when updating ptes to increase permissiveness > of protection (increase access authority). Book3S does not require > TLB flushing in this case, and it is not done on hash. This patch > avoids the

[PATCH] powerpc/64s/radix: reset mm_cpumask for single thread process when possible

When a single-threaded process has a non-local mm_cpumask and requires a full PID tlbie invalidation, use that as an opportunity to reset the cpumask back to the current CPU we're running on. No other thread can concurrently switch to this mm, because it must have had a reference on mm_users

[PATCH 2/2] powerpc/64s/radix: do not flush TLB on spurious fault

In the case of a spurious fault (which can happen due to a race with another thread that changes the page table), the default Linux mm code calls flush_tlb_page for that address. This is not required because the pte will be re-fetched. Hash does not wire this up to a hardware TLB flush for this

[PATCH 1/2] powerpc/64s/radix: do not flush TLB when relaxing access

Radix flushes the TLB when updating ptes to increase permissiveness of protection (increase access authority). Book3S does not require TLB flushing in this case, and it is not done on hash. This patch avoids the flush for radix. >From Power ISA v3.0B, p.1090: Setting a Reference or Change

[PATCH 0/2] powerpc/64s/radix: avoid unnecessary TLB flushes on fault

These two patches make radix match hash and not flush the TLB after fixing up faults unnecessarily. There was some concern that accelerators need to have this flush, but nothing is documented or commented, so it should just be removed. We have a coprocessor count in the mm context now, and that