> -Original Message-
> From patchwork Sun Sep 20 04:29:53 2015
>
> Content-Type: text/plain; charset="utf-8"
>
> MIME-Version: 1.0
>
> Content-Tran
On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote:
> Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer
> dereference in order to avoid access to potentially freed memory.
>
> Use 'of_get_next_parent()' to simplify the while() loop and avoid the
> need of a temp variable
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 ge
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 valu
Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer
dereference in order to avoid access to potentially freed memory.
Use 'of_get_next_parent()' to simplify the while() loop and avoid the
need of a temp variable.
Signed-off-by: Christophe JAILLET
---
v2: Use of_property_read_u32
On Thu, Sep 24, 2015 at 04:00:23PM +0200, Andrzej Hajda wrote:
> The function can return negative value.
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107
>
On Wed, Sep 23, 2015 at 06:06:22PM +0300, Laurentiu Tudor wrote:
> The register is not currently used in the base kernel
> but will be in a forthcoming kvm patch.
>
> Signed-off-by: Laurentiu Tudor
Thanks, applied to my kvm-ppc-next branch.
Paul.
___
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 CPU 1
> > -
Similar to commit b6541db ("powerpc/eeh: Block PCI config access
upon frozen PE"), this blocks the PCI config space of Broadcom
Shiner adapter until PE reset is completed, to avoid recursive
fenced PHB when dumping PCI config registers during the period
of error recovery.
~# lspci -ns 0003:03:0
On Thu, Oct 15, 2015 at 11:11:01AM +0800, Boqun Feng wrote:
> Hi Paul,
>
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> [snip]
> > > To that end, the herd tool can make a diagram of what it thought
> > > happene
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, Michael Ellerman
> >> wrote:
> >> > On Wed, 2015-23-09 at 05:40:34 UTC, Michael E
Hi Paul,
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
[snip]
> > 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
> -Original Message-
> From: Wood Scott-B07421
> Sent: 2015年10月15日 4:36
> To: Hou Zhiqiang-B48286
> Cc: linuxppc-dev@lists.ozlabs.org; ga...@kernel.crashing.org;
> b...@kernel.crashing.org; pau...@samba.org; m...@ellerman.id.au;
> devicet...@vger.kernel.org; robh...@kernel.org; pawel.m...
On Thu, Oct 15, 2015 at 09:22:26AM +0800, Boqun Feng wrote:
> On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Oct 14, 2015 at 01:19
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > > Suppose we have somethi
On Thu, 2015-10-15 at 09:24 +1100, Sam Bobroff wrote:
> On Wed, Oct 14, 2015 at 08:39:09PM +1100, Michael Ellerman wrote:
> > On Thu, 2015-10-08 at 11:50 +1100, Sam Bobroff wrote:
> > > The paca display is already more than 24 lines, which can be problematic
> > > if you have an old school 80x24 te
On Thu, Oct 15, 2015 at 08:53:21AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > > Suppose we have somethi
On Wed, Oct 14, 2015 at 02:44:53PM -0700, Paul E. McKenney wrote:
> On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > > Suppose we have something like the following, where "a" and "x" are both
> > > initially ze
When building against older kernel headers, currently the tm-syscall
test fails to build because PPC_FEATURE2_HTM_NOSC is not defined.
Tweak the test so that if PPC_FEATURE2_HTM_NOSC is not defined it still
builds, but prints a warning at run time and marks the test as skipped.
Signed-off-by: Mic
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)
>
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)
> or map IRQ7 to sie 0(MPIC_EILR7=0xf0) and prio=0xf(MPIC_EIVPR7=0x
On Wed, Oct 14, 2015 at 08:38:15PM +1100, Michael Ellerman wrote:
> On Wed, 2015-10-14 at 18:00 +1100, Sam Bobroff wrote:
> > On Tue, Oct 13, 2015 at 08:38:42PM +1100, Michael Ellerman wrote:
> > > On Tue, 2015-13-10 at 01:49:28 UTC, Sam bobroff wrote:
> > > > This patch provides individual system
On Wed, Oct 14, 2015 at 08:39:09PM +1100, Michael Ellerman wrote:
> On Thu, 2015-10-08 at 11:50 +1100, 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
On Wed, Oct 14, 2015 at 11:04:19PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> > Suppose we have something like the following, where "a" and "x" are both
> > initially zero:
> >
> > CPU 0 CPU 1
> > -
On Wed, Oct 14, 2015 at 01:19:17PM -0700, Paul E. McKenney wrote:
> Suppose we have something like the following, where "a" and "x" are both
> initially zero:
>
> CPU 0 CPU 1
> - -
>
> WRITE_ONCE(x, 1); WR
On Tue, 2015-10-13 at 19:29 +0800, Zhiqiang Hou wrote:
> From: Harninder Rai
>
> Signed-off-by: Harninder Rai
> Signed-off-by: Minghuan Lian
> Change-Id: I4355add4a92d1fcf514843aea5ecadd2e2517969
> Reviewed-on: http://git.am.freescale.net:8181/2454
> Reviewed-by: Zang Tiefei-R61911
> Reviewed-
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, which is not a full barrier.
>
> So replace PPC_RELEASE_BARRIER and PPC_ACQ
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)
or map IRQ7 to sie 0(MPIC_EILR7=0xf0) and prio=0xf(MPIC_EIVPR7=0x4f)
There is no need for SW handler because IRQ7 will be routed to t
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, Michael Ellerman
>> wrote:
>> > On Wed, 2015-23-09 at 05:40:34 UTC, Michael Ellerman wrote:
>> >> Arch Makefiles can set KBUILD_DEFCONFIG to tel
Implement cmpxchg{,64}_relaxed and atomic{,64}_cmpxchg_relaxed, based on
which _release variants can be built.
To avoid superfluous barriers in _acquire variants, we implement these
operations with assembly code rather use __atomic_op_acquire() to build
them automatically.
For the same reason, we
Implement xchg_relaxed and atomic{,64}_xchg_relaxed, based on these
_relaxed variants, release/acquire variants and fully ordered versions
can be built.
Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
barriers.
Signed-off-by: Boqun Feng
---
arch/powerpc/include/asm/atomic.
On powerpc, acquire and release semantics can be achieved with
lightweight barriers("lwsync" and "ctrl+isync"), which can be used to
implement __atomic_op_{acquire,release}.
For release semantics, since we only need to ensure all memory accesses
that issue before must take effects before the -stor
Some architectures may have their special barriers for acquire, release
and fence semantics, so that general memory barriers(smp_mb__*_atomic())
in the default __atomic_op_*() may be too strong, so allow architectures
to define their own helpers which can overwrite the default helpers.
Signed-off-
Some atomic operations now have _relaxed/acquire/release variants, this
patch then adds some trivial tests for two purpose:
1. test the behavior of these new operations in single-CPU
environment.
2. make their code generated before we actually use them somewhere,
so that
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, which is not a full barrier.
So replace PPC_RELEASE_BARRIER and PPC_ACQUIRE_BARRIER with
PPC_ATOMIC_ENTRY_BARRIER and PPC_ATOMIC_EXIT_BARRIER
Hi all,
This is v4 of the series.
Link for v1: https://lkml.org/lkml/2015/8/27/798
Link for v2: https://lkml.org/lkml/2015/9/16/527
Link for v3: https://lkml.org/lkml/2015/10/12/368
Changes since v3:
* avoid to introduce smp_acquire_barrier__after_atomic()
(Will Deacon)
* e
Hi Christoph,
On 12.10.2015 [14:06:51 -0700], Nishanth Aravamudan wrote:
> On 06.10.2015 [02:51:36 -0700], Christoph Hellwig wrote:
> > Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define
> > with an #ifndef in common code?
>
> On Power, since it's technically variable, we'd
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?
> >
> > I noticed that sparc has a IOMMU_PAGE_SHIFT already, fwiw.
>
> Sorry,
James, would you please review and ack this patch, and patch 01/25 also?
On Sun, 23 Aug 2015, Finn Thain wrote:
> By implementing an arch_nvram_ops struct, any platform can re-use the
> drivers/char/nvram module without needing any arch-specific code
> in that module. Atari does so here.
>
> At
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 given processor. Currently we
>> use VPHN node ID information only aft
On Wed, 2015-10-14 at 11:33 +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 05:26:53PM +0800, Boqun Feng wrote:
> > Michael and Peter, rest of this patchset depends on commits which are
> > currently in the locking/core branch of the tip, so I would like it as a
> > whole queued there. Besid
On Wed, Oct 14, 2015 at 09:47:35AM +0800, Boqun Feng wrote:
> On Tue, Oct 13, 2015 at 04:04:27PM +0100, Will Deacon wrote:
> > On Tue, Oct 13, 2015 at 10:58:30PM +0800, Boqun Feng wrote:
> > > On Tue, Oct 13, 2015 at 03:43:33PM +0100, Will Deacon wrote:
> > > > Putting a barrier in the middle of th
On Thu, 2015-10-08 at 11:50 +1100, 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.
>
> This patch adds a new command "
On Wed, 2015-10-14 at 18:00 +1100, Sam Bobroff wrote:
> On Tue, Oct 13, 2015 at 08:38:42PM +1100, Michael Ellerman wrote:
> > 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
On Wed, Oct 14, 2015 at 05:26:53PM +0800, Boqun Feng wrote:
> Michael and Peter, rest of this patchset depends on commits which are
> currently in the locking/core branch of the tip, so I would like it as a
> whole queued there. Besides, I will keep this patch Cc'ed to stable in
> future versions,
On Wed, Oct 14, 2015 at 10:06:13AM +0200, Peter Zijlstra wrote:
> On Wed, Oct 14, 2015 at 08:51:34AM +0800, Boqun Feng wrote:
> > On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
>
> > > Thanks for fixing this. In future you should send a patch like this as a
> > > separate patch.
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 durin
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 during boot time inside the function numa_setup_cpu, we still
query the O
On Wed, Oct 14, 2015 at 08:51:34AM +0800, Boqun Feng wrote:
> On Wed, Oct 14, 2015 at 11:10:00AM +1100, Michael Ellerman wrote:
> > Thanks for fixing this. In future you should send a patch like this as a
> > separate patch. I've not been paying attention to it because I assumed it
> > was
>
> G
ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm
Signed-off-by: Zhao Qiang
---
Changes for v2:
- move code to driver/soc
Changes for v3:
- change drivers/soc/qe to drivers/soc/fsl-qe
Changes for v4:
- move drivers/soc
Use subsys_initcall to init qe to adapt ARM architecture.
Remove qe_reset from PowerPC platform file.
Signed-off-by: Zhao Qiang
---
Changes for v12:
- Nil
arch/powerpc/platforms/83xx/km83xx.c | 2 --
arch/powerpc/platforms/83xx/mpc832x_mds.c | 2 --
arch/powerpc/platforms/83xx/mp
QE and CPM have the same muram, they use the same management
functions. Now QE support both ARM and PowerPC, it is necessary
to move QE to "driver/soc", so move the muram management functions
from cpm_common to qe_common for preparing to move QE code to "driver/soc"
Signed-off-by: Zhao Qiang
---
Use genalloc to manage CPM/QE muram instead of rheap.
Signed-off-by: Zhao Qiang
---
Changes for v9:
- splitted from patch 3/5, modify cpm muram management functions.
Changes for v10:
- modify cpm muram first, then move to qe_common
- modify commit.
Changes for v11:
Add new algo for genalloc, it reserve a specific region of
memory matching the size requirement (no alignment constraint)
Signed-off-by: Zhao Qiang
---
Changes for v9:
- reserve a specific region, if the return region
- is not during the specific region, return fail.
Changes for v
Bytes alignment is required to manage some special RAM,
so add gen_pool_first_fit_align to genalloc,
meanwhile add gen_pool_alloc_data to pass data to
gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper)
Signed-off-by: Zhao Qiang
---
Changes for v6:
- patches set v6 include a new
On Tue, Oct 13, 2015 at 08:38:42PM +1100, Michael Ellerman wrote:
> 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,
56 matches
Mail list logo
