Re: [FIX] powerpc: discard .exit.data at runtime

On Wed, 2015-07-10 at 23:28:28 UTC, Stephen Rothwell wrote: > .exit.text is discarded at run time and there are some references from > that to .exit.data, so we need to discard .exit.data at run time as well. > > Fixes these errors: > > `.exit.data' referenced in section `.exit.text' of

Re: powerpc: Delete old orphaned PrPMC 280/2800 DTS and boot file.

On Tue, 2015-13-10 at 23:20:51 UTC, Paul Gortmaker wrote: > In commit 3c8464a9b12bf83807b6e2c896d7e7b633e1cae7 ("powerpc: > Delete old PrPMC 280/2800 support") we got rid of most of the C > code, and the Makefile/Kconfig hooks, but it seems I left the > platform's DTS file orphaned in the tree as

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

Dammit guys, it's never simple is it? On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote: > To that end, the herd tool can make a diagram of what it thought > happened, and I have attached it. I used this diagram to try and force > this scenario at

Re: powerpc/pci: export pcibios_free_controller()

On Thu, 2015-10-09 at 06:28:34 UTC, Andrew Donnellan wrote: > Export pcibios_free_controller(), so it can be used by the cxl module to > free virtual PHBs. > > Signed-off-by: Andrew Donnellan Applied to powerpc next, thanks.

Re: drivers/macintosh: adb: fix misleading Kconfig help text

On Thu, 2015-01-10 at 19:41:40 UTC, Aaro Koskinen wrote: > CONFIG_INPUT_KEYBDEV does not exist and no additional keyboard-specific > options are needed to get the keyboard working. > > Signed-off-by: Aaro Koskinen Applied to powerpc next, thanks.

Re: powerpc/numa: Use of_get_next_parent to simplify code

On Sun, 2015-11-10 at 20:23:27 UTC, Christophe Jaillet wrote: > of_get_next_parent can be used to simplify the while() loop and > avoid the need of a temp variable. > > Signed-off-by: Christophe JAILLET Applied to powerpc next, thanks.

Re: [1/4] powerpc/pseries: Make PCI non-optional

On Thu, 2015-01-10 at 06:44:31 UTC, Michael Ellerman wrote: > The pseries build with PCI=n looks to have been broken for at least 5 > years, and no one's noticed or cared. > > Following the obvious breakages backward, the first commit I can find > that builds is the parent of 2eb4afb69ff3

Re: powerpc/eeh: atomic_dec_if_positive() to update passthru count

On Thu, 2015-27-08 at 05:58:27 UTC, Gavin Shan wrote: > No need to have two atomic opertions (update and fetch/check) when > decreasing PE's number of passed devices as one atomic operation > is enough. > > Signed-off-by: Gavin Shan Applied to powerpc next, thanks.

Re: [v3,1/2] powerpc/xmon: Paged output for paca display

On Thu, 2015-08-10 at 00:50:23 UTC, Sam bobroff wrote: > The paca display is already more than 24 lines, which can be problematic > if you have an old school 80x24 terminal, or more likely you are on a > virtual terminal which does not scroll for whatever reason. ... > Signed-off-by: Sam Bobroff

Re: [v2,1/1] powerpc: Individual System V IPC system calls

On Tue, 2015-13-10 at 01:49:28 UTC, Sam bobroff wrote: > This patch provides individual system call numbers for the following > System V IPC system calls, on PowerPC, so that they do not need to be > multiplexed: > * semop, semget, semctl, semtimedop > * msgsnd, msgrcv, msgget, msgctl > * shmat,

Re: cxl: Free virtual PHB when removing

On Tue, 2015-13-10 at 04:09:44 UTC, Andrew Donnellan wrote: > When adding a vPHB in cxl_pci_vphb_add(), we allocate a pci_controller > struct using pcibios_alloc_controller(). However, we don't free it in > cxl_pci_vphb_remove(), causing a leak. > > Call pcibios_free_controller() in

Re: powerpc/mpc5xxx: Use of_get_next_parent to simplify code

On Sun, 2015-11-10 at 20:27:40 UTC, Christophe Jaillet wrote: > of_get_next_parent can be used to simplify the while() loop and > avoid the need of a temp variable. > > Signed-off-by: Christophe JAILLET Applied to powerpc next, thanks.

Re: [PATCH] scripts/kconfig/Makefile: Fix KBUILD_DEFCONFIG check when building with O=

Dne 15.10.2015 v 08:05 Michael Ellerman napsal(a): > My recent commit d2036f30cfe1 ("scripts/kconfig/Makefile: Allow > KBUILD_DEFCONFIG to be a target"), contained a bug in that when it > checks if KBUILD_DEFCONFIG is a file it forgets to prepend $(srctree) to > the path. > > This causes the

RE: [v3,1/5] powerpc/fsl: Move fsl_guts.h out of arch/powerpc

> -Original Message- > From patchwork Sun Sep 20 04:29:53 2015 > > Content-Type: text/plain; charset="utf-8" > > MIME-Version: 1.0 > >

Re: devicetree and IRQ7 mapping for T1042(mpic)

On Thu, 2015-10-15 at 07:11 +, Joakim Tjernlund wrote: > On Wed, 2015-10-14 at 19:11 -0500, Scott Wood wrote: > > On Wed, 2015-10-14 at 19:37 +, Joakim Tjernlund wrote: > > > I am trying to figure out how to describe/map external IRQ7 in the > > > devicetree. > > > > > > Basically either

Re: [RFC, 1/2] scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target

Dne 15.10.2015 v 05:27 Michael Ellerman napsal(a): > On Wed, 2015-10-14 at 09:54 -0700, Olof Johansson wrote: >> On Tue, Oct 13, 2015 at 4:43 PM, Michael Ellerman >> wrote: >>> On Tue, 2015-10-13 at 14:02 -0700, Olof Johansson wrote: On Fri, Oct 2, 2015 at 12:47 AM,

Re: devicetree and IRQ7 mapping for T1042(mpic)

On Wed, 2015-10-14 at 19:11 -0500, Scott Wood wrote: > On Wed, 2015-10-14 at 19:37 +, Joakim Tjernlund wrote: > > I am trying to figure out how to describe/map external IRQ7 in the > > devicetree. > > > > Basically either IRQ7 to be left alone by Linux(becase u-boot already set > > it up) >

Re: [PATCH V5 3/6] powerpc/powernv: use one M64 BAR in Single PE mode for one VF BAR

On Wed, Oct 14, 2015 at 12:15:32PM +1100, Gavin Shan wrote: >On Tue, Oct 13, 2015 at 01:29:44PM +0800, Wei Yang wrote: >>On Tue, Oct 13, 2015 at 02:32:49PM +1100, Gavin Shan wrote: >>>On Tue, Oct 13, 2015 at 10:50:42AM +0800, Wei Yang wrote: On Tue, Oct 13, 2015 at 10:55:27AM +1100, Gavin Shan

Re: [PATCH] scripts/kconfig/Makefile: Fix KBUILD_DEFCONFIG check when building with O=

On Thu, 2015-10-15 at 09:27 +0200, Michal Marek wrote: > Dne 15.10.2015 v 08:05 Michael Ellerman napsal(a): > > My recent commit d2036f30cfe1 ("scripts/kconfig/Makefile: Allow > > KBUILD_DEFCONFIG to be a target"), contained a bug in that when it > > checks if KBUILD_DEFCONFIG is a file it forgets

[PATCH] selfttest/powerpc: Add memory page migration tests

This adds two tests for memory page migration. One for normal page migration which works for both 4K or 64K base page size kernel and the other one is for 16MB huge page migration which will work both 4K or 64K base page sized 16MB huge pages as and when we support huge page migration.

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 11:35:44AM +0100, Will Deacon wrote: > Dammit guys, it's never simple is it? > > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote: > > To that end, the herd tool can make a diagram of what it thought > > happened, and I have attached it. I used this

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 10:49:23PM +0800, Boqun Feng wrote: > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote: > > On Wed, Oct 14, 2015 at 11:55:56PM +0800, Boqun Feng wrote: > > > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_ > > > versions all need to

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 11:35:44AM +0100, Will Deacon wrote: > > So arm64 is ok. Doesn't lwsync order store->store observability for PPC? > I did some litmus and put the result here. My understanding might be wrong, and I think Paul can explain the lwsync and store->store order better ;-)

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 11:35:10AM +0100, Will Deacon wrote: > Dammit guys, it's never simple is it? I re-read this and it's even more confusing than I first thought. > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote: > > To that end, the herd tool can make a diagram of what it

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote: > On Wed, Oct 14, 2015 at 11:55:56PM +0800, Boqun Feng wrote: > > According to memory-barriers.txt, xchg, cmpxchg and their atomic{,64}_ > > versions all need to imply a full barrier, however they are now just > > RELEASE+ACQUIRE,

Re: [PATCH v2 1/3] ppc64: Fix warnings

On Tue, Oct 06, 2015 at 05:55:48PM -0500, Scott Wood wrote: > Produce a warning-free build on ppc64 (at least, when built as 64-bit > userspace -- if a 64-bit binary for ppc64 is a requirement, why is -m64 > set only on purgatory?). Mostly unused (or write-only) variable > warnings, but also one

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

On Thu, 2015-10-15 at 21:00 +0200, Laurent Vivier wrote: > On kexec, all secondary offline CPUs are onlined before > starting the new kernel, this is not done in the case of kdump. > > If kdump is configured and a kernel crash occurs whereas > some secondaries CPUs are offline (SMT=off), > the

Re: [PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

On Tue, Oct 06, 2015 at 05:55:50PM -0500, Scott Wood wrote: > It needs to know this because the SMP release mechanism for Freescale > book3e is different from when booting with normal hardware. In theory > we could simulate the normal spin table mechanism, but not (easily) at > the addresses

Re: [PATCH v2 2/3] ppc64: Avoid rfid if no need to clear MSR_LE

On Tue, Oct 06, 2015 at 05:55:49PM -0500, Scott Wood wrote: > Commit a304e2d82a8c3 ("ppc64: purgatory: Reset primary cpu endian to > big-endian) changed bctr to rfid. rfid is book3s-only and will cause a > fatal exception on book3e. > > Purgatory is an isolated environment which makes importing

Re: [PATCH] PPC: fix LOGMPP instruction opcode and inline asm

On Fri, 2015-10-16 at 12:20 +1100, Stewart Smith wrote: > Back in 9678cda when we started using the Micro Partition Prefetch Engine > in POWER8 for KVM, there were two mistakes introduced from the original > patch used for investigation and microbenchmarks. > > One mistake was that the opcode was

[PATCH] PPC: fix LOGMPP instruction opcode and inline asm

Back in 9678cda when we started using the Micro Partition Prefetch Engine in POWER8 for KVM, there were two mistakes introduced from the original patch used for investigation and microbenchmarks. One mistake was that the opcode was constructed incorrectly, putting the register in the wrong field

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

Hi Laurent, [auto build test ERROR on powerpc/next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Laurent-Vivier/powerpc-on-crash-kexec-ed-kernel-needs-all-CPUs-are-online/20151016-030306 config:

Re: [PATCH] PPC: fix LOGMPP instruction opcode and inline asm

Michael Ellerman writes: > On Fri, 2015-10-16 at 12:20 +1100, Stewart Smith wrote: >> Back in 9678cda when we started using the Micro Partition Prefetch Engine >> in POWER8 for KVM, there were two mistakes introduced from the original >> patch used for investigation and

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

On 14.10.2015 [08:42:51 -0700], Christoph Hellwig wrote: > Hi Nishanth, > > sorry for the late reply. > > > > On Power, since it's technically variable, we'd need a function. So are > > > you suggesting define'ing it to a function just on Power and leaving it > > > a constant elsewhere? > > > >

Re: [RFC] powerpc/numa: Use VPHN based node ID information on shared processor LPARs

On Wed, 2015-10-14 at 14:32 +0530, Anshuman Khandual wrote: > On shared processor LPARs, H_HOME_NODE_ASSOCIATIVITY hcall provides the > dynamic virtual-physical mapping for any given processor. Currently we > use VPHN node ID information only after getting either a PRRN or a VPHN > event. But

Re: [RFC] powerpc/numa: Use VPHN based node ID information on shared processor LPARs

On Wed, 2015-10-14 at 15:43 +0530, Anshuman Khandual wrote: > On 10/14/2015 02:49 PM, Michael Ellerman wrote: > > On Wed, 2015-10-14 at 14:32 +0530, Anshuman Khandual wrote: > >> On shared processor LPARs, H_HOME_NODE_ASSOCIATIVITY hcall provides the > >> dynamic virtual-physical mapping for any

Re: [PATCH v3 3/5] clk: qoriq: Add ls2080a support.

On 09/19, Scott Wood wrote: > LS2080A is the first implementation of the chassis 3 clockgen, which > has a different register layout than previous chips. It is also little > endian, unlike previous chips. > > Signed-off-by: Scott Wood > --- Acked-by: Stephen Boyd

Re: [PATCH v3 4/5] clk: Add consumer APIs for discovering possible parent clocks

On Sat, 2015-09-19 at 23:29 -0500, Scott Wood wrote: > Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed > __clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only > true provider API versions that operate on struct clk_hw. > > qoriq-cpufreq needs these functions in

Re: [PATCH v3 2/5] clk: qoriq: Move chip-specific knowledge into driver

On 09/19, Scott Wood wrote: > The device tree should describe the chips (or chip-like subblocks) in > the system, but it generally does not describe individual registers -- > it should identify, rather than describe, a programming interface. > > This has not been the case with the QorIQ clockgen

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

On Thu, 15 Oct 2015 21:00:58 +0200 Laurent Vivier wrote: > On kexec, all secondary offline CPUs are onlined before > starting the new kernel, this is not done in the case of kdump. > > If kdump is configured and a kernel crash occurs whereas > some secondaries CPUs are

Re: [RFC] powerpc/numa: Use VPHN based node ID information on shared processor LPARs

On 10/16/2015 07:54 AM, Michael Ellerman wrote: > On Wed, 2015-10-14 at 15:43 +0530, Anshuman Khandual wrote: >> On 10/14/2015 02:49 PM, Michael Ellerman wrote: >>> On Wed, 2015-10-14 at 14:32 +0530, Anshuman Khandual wrote: On shared processor LPARs, H_HOME_NODE_ASSOCIATIVITY hcall provides

Re: [RFC] powerpc/numa: Use VPHN based node ID information on shared processor LPARs

On 10/16/2015 07:57 AM, Michael Ellerman wrote: > On Wed, 2015-10-14 at 14:32 +0530, Anshuman Khandual wrote: >> On shared processor LPARs, H_HOME_NODE_ASSOCIATIVITY hcall provides the >> dynamic virtual-physical mapping for any given processor. Currently we >> use VPHN node ID information only

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 03:50:44PM +0100, Will Deacon wrote: > On Thu, Oct 15, 2015 at 11:35:10AM +0100, Will Deacon wrote: > > Dammit guys, it's never simple is it? > > I re-read this and it's even more confusing than I first thought. > > > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E.

Re: [PATCH tip/locking/core v4 1/6] powerpc: atomic: Make *xchg and *cmpxchg a full barrier

On Thu, Oct 15, 2015 at 12:48:03PM +0800, Boqun Feng wrote: > On Wed, Oct 14, 2015 at 08:07:05PM -0700, Paul E. McKenney wrote: > > On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote: > [snip] > > > > > > I'm afraid more than that, the above litmus also shows that > > > > > > CPU 0

[PATCH] scripts/kconfig/Makefile: Fix KBUILD_DEFCONFIG check when building with O=

My recent commit d2036f30cfe1 ("scripts/kconfig/Makefile: Allow KBUILD_DEFCONFIG to be a target"), contained a bug in that when it checks if KBUILD_DEFCONFIG is a file it forgets to prepend $(srctree) to the path. This causes the build to fail when building out of tree (with O=), and when the

[PATCH] book3s_hv: Handle H_DOORBELL on the guest exit path

Currently a CPU running a guest can receive a H_DOORBELL in the following two cases: 1) When the CPU is napping due to CEDE or there not being a guest vcpu. 2) The CPU is running the guest vcpu. Case 1), the doorbell message is not cleared since we were waking up from nap. Hence when the EE bit

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

On kexec, all secondary offline CPUs are onlined before starting the new kernel, this is not done in the case of kdump. If kdump is configured and a kernel crash occurs whereas some secondaries CPUs are offline (SMT=off), the new kernel is not able to start them and displays some "Processor X is