* Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
From: Yasuaki Ishimatsu @ 2014-12-01 1:17 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, linux-kernel, Pekka Enberg, linux-mm,
David Rientjes, Joonsoo Kim, Andrew Morton, Christoph Lameter
In-Reply-To: <20141201004210.GA11234@drongo>
(2014/12/01 9:42), Paul Mackerras wrote:
> On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote:
>> (2014/12/01 7:16), Paul Mackerras wrote:
>>> The bounds check for nodeid in ____cache_alloc_node gives false
>>> positives on machines where the node IDs are not contiguous, leading
>>> to a panic at boot time. For example, on a POWER8 machine the node
>>> IDs are typically 0, 1, 16 and 17. This means that num_online_nodes()
>>> returns 4, so when ____cache_alloc_node is called with nodeid = 16 the
>>> VM_BUG_ON triggers.
>>
>> Do you have the call trace? If you have it, please add it in the description.
>
> I can get it easily enough.
>
>>> To fix this, we instead compare the nodeid with MAX_NUMNODES, and
>>> additionally make sure it isn't negative (since nodeid is an int).
>>> The check is there mainly to protect the array dereference in the
>>> get_node() call in the next line, and the array being dereferenced is
>>> of size MAX_NUMNODES. If the nodeid is in range but invalid, the
>>> BUG_ON in the next line will catch that.
>>>
>>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>>
>> Do you need to backport it into -stable kernels?
>
> It does need to go to stable, yes, for 3.10 and later.
>
>>> ---
>>> diff --git a/mm/slab.c b/mm/slab.c
>>> index eb2b2ea..f34e053 100644
>>> --- a/mm/slab.c
>>> +++ b/mm/slab.c
>>> @@ -3076,7 +3076,7 @@ static void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
>>> void *obj;
>>> int x;
>>>
>>
>>> - VM_BUG_ON(nodeid > num_online_nodes());
>>> + VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES);
>>
>> How about use:
>> VM_BUG_ON(!node_online(nodeid));
>
> That would not be better, since node_online() doesn't bounds-check its
> argument.
>
Ah. You are right.
>> When allocating the memory, the node of the memory being allocated must be
>> online. But your code cannot check the condition.
>
> The following two lines:
>
>>> n = get_node(cachep, nodeid);
>>> BUG_ON(!n);
>
> effectively check that condition already, as I tried to explain in the
> commit message.
O.K. I understood.
Thansk,
Yasuaki Ishimatsu
>
> Regards,
> Paul.
>
^ permalink raw reply
* Re: [PATCH 6/8 v2] crypto: replace memset by memzero_explicit
From: Michael Ellerman @ 2014-12-01 0:58 UTC (permalink / raw)
To: Julia Lawall
Cc: Herbert Xu, kernel-janitors, linux-kernel, Paul Mackerras,
linux-crypto, linuxppc-dev, David S. Miller
In-Reply-To: <1417367029-32762-7-git-send-email-Julia.Lawall@lip6.fr>
On Sun, 2014-11-30 at 18:03 +0100, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Memset on a local variable may be removed when it is called just before the
> variable goes out of scope. Using memzero_explicit defeats this
> optimization. A simplified version of the semantic patch that makes this
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> Daniel Borkmann suggested that these patches could go through Herbert Xu's
> cryptodev tree.
That's fine by me:
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
From: Paul Mackerras @ 2014-12-01 0:42 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linuxppc-dev, linux-kernel, Pekka Enberg, linux-mm,
David Rientjes, Joonsoo Kim, Andrew Morton, Christoph Lameter
In-Reply-To: <547BB2F0.5040708@jp.fujitsu.com>
On Mon, Dec 01, 2014 at 09:14:40AM +0900, Yasuaki Ishimatsu wrote:
> (2014/12/01 7:16), Paul Mackerras wrote:
> >The bounds check for nodeid in ____cache_alloc_node gives false
> >positives on machines where the node IDs are not contiguous, leading
> >to a panic at boot time. For example, on a POWER8 machine the node
> >IDs are typically 0, 1, 16 and 17. This means that num_online_nodes()
> >returns 4, so when ____cache_alloc_node is called with nodeid = 16 the
> >VM_BUG_ON triggers.
>
> Do you have the call trace? If you have it, please add it in the description.
I can get it easily enough.
> >To fix this, we instead compare the nodeid with MAX_NUMNODES, and
> >additionally make sure it isn't negative (since nodeid is an int).
> >The check is there mainly to protect the array dereference in the
> >get_node() call in the next line, and the array being dereferenced is
> >of size MAX_NUMNODES. If the nodeid is in range but invalid, the
> >BUG_ON in the next line will catch that.
> >
> >Signed-off-by: Paul Mackerras <paulus@samba.org>
>
> Do you need to backport it into -stable kernels?
It does need to go to stable, yes, for 3.10 and later.
> >---
> >diff --git a/mm/slab.c b/mm/slab.c
> >index eb2b2ea..f34e053 100644
> >--- a/mm/slab.c
> >+++ b/mm/slab.c
> >@@ -3076,7 +3076,7 @@ static void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
> > void *obj;
> > int x;
> >
>
> >- VM_BUG_ON(nodeid > num_online_nodes());
> >+ VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES);
>
> How about use:
> VM_BUG_ON(!node_online(nodeid));
That would not be better, since node_online() doesn't bounds-check its
argument.
> When allocating the memory, the node of the memory being allocated must be
> online. But your code cannot check the condition.
The following two lines:
> > n = get_node(cachep, nodeid);
> > BUG_ON(!n);
effectively check that condition already, as I tried to explain in the
commit message.
Regards,
Paul.
^ permalink raw reply
* Re: [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
From: Yasuaki Ishimatsu @ 2014-12-01 0:14 UTC (permalink / raw)
To: Paul Mackerras, linux-mm
Cc: Andrew Morton, linux-kernel, Pekka Enberg, linuxppc-dev,
David Rientjes, Christoph Lameter, Joonsoo Kim
In-Reply-To: <20141130221606.GA25929@iris.ozlabs.ibm.com>
(2014/12/01 7:16), Paul Mackerras wrote:
> The bounds check for nodeid in ____cache_alloc_node gives false
> positives on machines where the node IDs are not contiguous, leading
> to a panic at boot time. For example, on a POWER8 machine the node
> IDs are typically 0, 1, 16 and 17. This means that num_online_nodes()
> returns 4, so when ____cache_alloc_node is called with nodeid = 16 the
> VM_BUG_ON triggers.
Do you have the call trace? If you have it, please add it in the description.
> To fix this, we instead compare the nodeid with MAX_NUMNODES, and
> additionally make sure it isn't negative (since nodeid is an int).
> The check is there mainly to protect the array dereference in the
> get_node() call in the next line, and the array being dereferenced is
> of size MAX_NUMNODES. If the nodeid is in range but invalid, the
> BUG_ON in the next line will catch that.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Do you need to backport it into -stable kernels?
> ---
> diff --git a/mm/slab.c b/mm/slab.c
> index eb2b2ea..f34e053 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -3076,7 +3076,7 @@ static void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
> void *obj;
> int x;
>
> - VM_BUG_ON(nodeid > num_online_nodes());
> + VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES);
How about use:
VM_BUG_ON(!node_online(nodeid));
When allocating the memory, the node of the memory being allocated must be
online. But your code cannot check the condition.
Thanks,
Yasuaki Ishimatsu
> n = get_node(cachep, nodeid);
> BUG_ON(!n);
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [3/3] powerpc/eeh: Fix missed PE#0 on P7IOC
From: Gavin Shan @ 2014-11-30 22:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <20141126040910.AE17D14017B@ozlabs.org>
On Wed, Nov 26, 2014 at 03:09:10PM +1100, Michael Ellerman wrote:
>On Mon, 2014-24-11 at 22:27:00 UTC, Gavin Shan wrote:
>> PE#0 should be regarded as valid for P7IOC, while it's invalid for
>> PHB3. The patch adds flag EEH_VALID_PE_ZERO to differentiate those
>> two cases. Without the patch, we possibly see frozen PE#0 state is
>> cleared without EEH recovery taken on P7IOC as following kernel logs
>> indicate:
>
>This sounds like an urgent fix but I'm not sure.
>
You can pick it up for next release. Usually, we shouldn't see errors
from PE#0. Something I did to force that for testing purpose: disable
memory windows of the root complex and then access one of memory BARs
on one adapter behind the root complex.
Thanks,
Gavin
>cheers
>
^ permalink raw reply
* Re: [2/3] powerpc/powernv: Replace OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE
From: Gavin Shan @ 2014-11-30 22:23 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <20141126040751.3649B14017B@ozlabs.org>
On Wed, Nov 26, 2014 at 03:07:51PM +1100, Michael Ellerman wrote:
>On Mon, 2014-24-11 at 22:26:59 UTC, Gavin Shan wrote:
>> The flag passed to ioda_eeh_phb_reset() should be EEH_RESET_DEACTIVATE,
>> which is translated to OPAL_DEASSERT_RESET or something else by the
>> EEH backend accordingly.
>>
>> The patch replaces OPAL_DEASSERT_RESET with EEH_RESET_DEACTIVATE for
>> ioda_eeh_phb_reset().
>
>What is the symptom? Does it not work at all or is it just a cosmetic issue?
>ie. should I send this to Linus ASAP or can it wait for the next release.
>
>Looks like this went in as 361f2a2a1536 ("powrpc/powernv: Reset PHB in kdump
>kernel") in 3.16. Should it go to stable?
>
It's just a cosmetic issue and please pick it up for next release.
Thanks,
Gavin
>cheers
>
^ permalink raw reply
* [PATCH] slab: Fix nodeid bounds check for non-contiguous node IDs
From: Paul Mackerras @ 2014-11-30 22:16 UTC (permalink / raw)
To: linux-mm
Cc: Andrew Morton, linux-kernel, Pekka Enberg, linuxppc-dev,
David Rientjes, Christoph Lameter, Joonsoo Kim
The bounds check for nodeid in ____cache_alloc_node gives false
positives on machines where the node IDs are not contiguous, leading
to a panic at boot time. For example, on a POWER8 machine the node
IDs are typically 0, 1, 16 and 17. This means that num_online_nodes()
returns 4, so when ____cache_alloc_node is called with nodeid = 16 the
VM_BUG_ON triggers.
To fix this, we instead compare the nodeid with MAX_NUMNODES, and
additionally make sure it isn't negative (since nodeid is an int).
The check is there mainly to protect the array dereference in the
get_node() call in the next line, and the array being dereferenced is
of size MAX_NUMNODES. If the nodeid is in range but invalid, the
BUG_ON in the next line will catch that.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/mm/slab.c b/mm/slab.c
index eb2b2ea..f34e053 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3076,7 +3076,7 @@ static void *____cache_alloc_node(struct kmem_cache *cachep, gfp_t flags,
void *obj;
int x;
- VM_BUG_ON(nodeid > num_online_nodes());
+ VM_BUG_ON(nodeid < 0 || nodeid >= MAX_NUMNODES);
n = get_node(cachep, nodeid);
BUG_ON(!n);
^ permalink raw reply related
* [PATCH] KVM: PPC: Enable in kernel XICS emulation by default
From: Anton Blanchard @ 2014-11-30 19:46 UTC (permalink / raw)
To: benh, paulus, mpe, agraf; +Cc: linuxppc-dev
The in kernel XICS emulation is faster than doing it all in QEMU
and it has got a lot of testing, so enable it by default
Signed-off-by: Anton Blanchard <anton@samba.org>
---
arch/powerpc/kvm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 602eb51..f5769f1 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -172,6 +172,7 @@ config KVM_XICS
depends on KVM_BOOK3S_64 && !KVM_MPIC
select HAVE_KVM_IRQCHIP
select HAVE_KVM_IRQFD
+ default y
---help---
Include support for the XICS (eXternal Interrupt Controller
Specification) interrupt controller architecture used on
--
2.1.0
^ permalink raw reply related
* [PATCH 6/8 v2] crypto: replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 17:03 UTC (permalink / raw)
To: Herbert Xu
Cc: kernel-janitors, linux-kernel, Paul Mackerras, linux-crypto,
linuxppc-dev, David S. Miller
In-Reply-To: <1417367029-32762-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// </smpl>
This change was suggested by Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
v2: fixed email address
arch/powerpc/crypto/sha1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/sha1.c b/arch/powerpc/crypto/sha1.c
index 0f88c7b..d3feba5 100644
--- a/arch/powerpc/crypto/sha1.c
+++ b/arch/powerpc/crypto/sha1.c
@@ -66,7 +66,7 @@ static int sha1_update(struct shash_desc *desc, const u8 *data,
src = data + done;
} while (done + 63 < len);
- memset(temp, 0, sizeof(temp));
+ memzero_explicit(temp, sizeof(temp));
partial = 0;
}
memcpy(sctx->buffer + partial, src, len - done);
^ permalink raw reply related
* [PATCH 0/8] replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 17:03 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-cifs, samba-technical, linux-usb, kernel-janitors,
linux-kernel, linux-raid, dm-devel, linux-crypto, sparclinux,
linuxppc-dev
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
// ------------------------------------------------------------------------
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
// </smpl>
^ permalink raw reply
* [PATCH 6/8] crypto: replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 16:59 UTC (permalink / raw)
To: Herbert Xu
Cc: herbert, kernel-janitors, linux-kernel, dborkman, Paul Mackerras,
linux-crypto, Julia Lawall, linuxppc-dev, David S. Miller
In-Reply-To: <1417366774-32412-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <julia@diku.dk>
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. A simplified version of the semantic patch that makes this
change is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
{
... when any
T x[...];
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
// </smpl>
This change was suggested by Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
Daniel Borkmann suggested that these patches could go through Herbert Xu's
cryptodev tree.
arch/powerpc/crypto/sha1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/sha1.c b/arch/powerpc/crypto/sha1.c
index 0f88c7b..d3feba5 100644
--- a/arch/powerpc/crypto/sha1.c
+++ b/arch/powerpc/crypto/sha1.c
@@ -66,7 +66,7 @@ static int sha1_update(struct shash_desc *desc, const u8 *data,
src = data + done;
} while (done + 63 < len);
- memset(temp, 0, sizeof(temp));
+ memzero_explicit(temp, sizeof(temp));
partial = 0;
}
memcpy(sctx->buffer + partial, src, len - done);
^ permalink raw reply related
* [PATCH 0/8] replace memset by memzero_explicit
From: Julia Lawall @ 2014-11-30 16:59 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-cifs, herbert, samba-technical, linux-usb, kernel-janitors,
dm-devel, linux-kernel, linux-raid, dborkman, linux-crypto,
sparclinux, linuxppc-dev
Memset on a local variable may be removed when it is called just before the
variable goes out of scope. Using memzero_explicit defeats this
optimization. The complete semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
local idexpression e;
type T,T1;
@@
{
... when any
T x[...];
... when any
when exists
(
e = (T1)x
|
e = (T1)&x[0]
)
... when any
when exists
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when != e
when strict
}
@@
identifier i,x;
local idexpression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
e = (T)&x
... when any
when exists
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when != e
when strict
}
// ------------------------------------------------------------------------
@@
identifier x;
type T,T1;
expression e;
@@
{
... when any
T x[...];
... when any
when exists
when != e = (T1)x
when != e = (T1)&x[0]
- memset
+ memzero_explicit
(x,
-0,
...)
... when != x
when strict
}
@@
identifier i,x;
expression e;
type T;
@@
{
... when any
struct i x;
... when any
when exists
when != e = (T)&x
- memset
+ memzero_explicit
(&x,
-0,
...)
... when != x
when strict
}
// </smpl>
^ permalink raw reply
* KVM XICS bug
From: Anton Blanchard @ 2014-11-30 10:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Alexey Kardashevskiy,
Alexander Graf
Cc: linuxppc-dev
Hi,
I've been seeing intermittent hangs when booting a KVM guest on a busy box.
Both host and guest are mainline (3.18-rc6). The backtrace looks like:
INFO: rcu_sched self-detected stall on CPU { 7} (t=8404 jiffies g=-299 c=-300 q=79)
Task dump for CPU 7:
swapper/7 R running task 11840 0 1 0x00000804
Call Trace:
[c0000007fa5434a0] [c0000000000cd684] sched_show_task+0xe4/0x160 (unreliable)
[c0000007fa543510] [c0000000000fa568] rcu_dump_cpu_stacks+0xe8/0x160
[c0000007fa543560] [c0000000000fe75c] rcu_check_callbacks+0x59c/0x8b0
[c0000007fa543680] [c000000000104a68] update_process_times+0x58/0xb0
[c0000007fa5436c0] [c000000000114e14] tick_periodic+0x44/0x110
[c0000007fa5436f0] [c000000000115208] tick_handle_periodic+0x38/0xc0
[c0000007fa543730] [c00000000001c7cc] __timer_interrupt+0x8c/0x240
[c0000007fa543780] [c00000000001ce90] timer_interrupt+0xa0/0xe0
[c0000007fa5437b0] [c0000000000099f4] restore_check_irq_replay+0x54/0x70
--- interrupt: 901 at arch_local_irq_restore+0x74/0x90
LR = arch_local_irq_restore+0x74/0x90
[c0000007fa543aa0] [c0000000000d1874] vtime_common_account_irq_enter+0x54/0x70 (unreliable)
[c0000007fa543ac0] [c00000000009c3d8] __do_softirq+0xd8/0x3a0
[c0000007fa543bb0] [c00000000009c9f8] irq_exit+0xc8/0x110
[c0000007fa543be0] [c00000000001ce94] timer_interrupt+0xa4/0xe0
[c0000007fa543c10] [c0000000000099f4] restore_check_irq_replay+0x54/0x70
--- interrupt: 901 at arch_local_irq_restore+0x5c/0x90
LR = arch_local_irq_restore+0x40/0x90
[c0000007fa543f00] [c000000000097864] cpu_notify+0x34/0x80 (unreliable)
[c0000007fa543f20] [c00000000003afa0] start_secondary+0x330/0x360
[c0000007fa543f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14
XICS in kernel emulation is disabled (I really need to update the defconfig).
It looks like we are looping in restore_check_irq_replay, replaying 0x500
exceptions. When we call H_XIRR to ask for the IRQ, QEMU tells us it's a
spurious IRQ.
Thinking up other ways to create similar stress, I ran a big SMP guest
on one core (with taskset). With no root filesystem this will just
panic and reboot until it hits the bug:
taskset -c 0 ~/qemu/ppc64-softmmu/qemu-system-ppc64 -enable-kvm -smp cores=16,threads=8 -m 4G -M pseries -nographic -vga none -kernel vmlinux
It usually hits in under 5 minutes.
I took a QEMU trace (I added a tracepoint to power7_set_irq) and we can
see QEMU is trying to cancel the exception:
xics_icp_accept 0.322 pid=71614 old_xirr=0xff000000 new_xirr=0xff000000
power7_set_irq 2.232 pid=71614 pin=0x0 level=0x0
xics_icp_accept 0.285 pid=71614 old_xirr=0xff000000 new_xirr=0xff000000
power7_set_irq 21.809 pid=71614 pin=0x0 level=0x0
xics_icp_accept 0.311 pid=71614 old_xirr=0xff000000 new_xirr=0xff000000
power7_set_irq 2.230 pid=71614 pin=0x0 level=0x0
To me it looks like the KVM and the QEMU view of the 0x500 exception
state has got out of sync. The patch below fixes the issue for me, but
we might want to dig further to understand why the state has got out of
sync. Any ideas?
Anton
--
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index bec82cd..cb0911f 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -60,7 +60,6 @@ void ppc_set_irq(PowerPCCPU *cpu, int n_IRQ, int level)
{
CPUState *cs = CPU(cpu);
CPUPPCState *env = &cpu->env;
- unsigned int old_pending = env->pending_interrupts;
if (level) {
env->pending_interrupts |= 1 << n_IRQ;
@@ -72,11 +71,9 @@ void ppc_set_irq(PowerPCCPU *cpu, int n_IRQ, int level)
}
}
- if (old_pending != env->pending_interrupts) {
#ifdef CONFIG_KVM
- kvmppc_set_interrupt(cpu, n_IRQ, level);
+ kvmppc_set_interrupt(cpu, n_IRQ, level);
#endif
- }
LOG_IRQ("%s: %p n_IRQ %d level %d => pending %08" PRIx32
"req %08x\n", __func__, env, n_IRQ, level,
^ permalink raw reply related
* Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
From: Benjamin Herrenschmidt @ 2014-11-30 9:01 UTC (permalink / raw)
To: David Laight
Cc: paulus@samba.org, rusty@rustcorp.com.au, Madhavan Srinivasan,
linuxppc-dev@lists.ozlabs.org, anton@samba.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FE54E@AcuExch.aculab.com>
On Fri, 2014-11-28 at 10:53 +0000, David Laight wrote:
> From: Benjamin Herrenschmidt
> > On Fri, 2014-11-28 at 08:45 +0530, Madhavan Srinivasan wrote:
> > > > Can't we just unconditionally clear at as long as we do that after we've
> > > > saved it ? In that case, it's just a matter for the fixup code to check
> > > > the saved version rather than the actual CR..
> > > >
> > > I use CR bit setting in the interrupt return path to enter the fixup
> > > section search. If we unconditionally clear it, we will have to enter
> > > the fixup section for every kernel return nip right?
> >
> > As I said above. Can't we look at the saved version ?
> >
> > IE.
> >
> > - On interrupt entry:
> >
> > * Save CR to CCR(r1)
> > * clear CR5
> >
> > - On exit
> >
> > * Check CCR(r1)'s CR5 field
> > * restore CR
>
> Actually there is no real reason why the 'fixup' can't be done
> during interrupt entry.
Other than if we crash, we get the wrong PC in the log etc... unlikely
but I tend to prefer this. Also if we ever allow something like a local
atomic on a faulting (uesrspace) address, we want a precise PC on entry.
Generally, we have a lot more entry path than exit path, it's easier to
keep the entry path simpler.
Cheers,
Ben.
> David
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] i2c-qoriq: modified compatibility for correct prescaler
From: Danielle Costantino @ 2014-11-30 4:30 UTC (permalink / raw)
To: Scott Wood
Cc: Valentin Longchamp, Linux device trees, Wolfram Sang,
Boschung, Rainer, Brunck, Holger, Linux I2C, Linux PowerPC Kernel
In-Reply-To: <1416966097.15957.171.camel@freescale.com>
I saw that this patch was marked as not applicable, but on most qoriq
devices the pre-scaler is 2 especially for p2020/p2010 devices
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
from the P2020 RM: p. 477
"Frequency divider ratio. Used to prescale the clock for bit rate
selection. The serial bit clock frequency of
SCL is equal to one half the platform ( CCB ) clock divided by the
designated divider ."
This means that the current dts for these devices are providing false
clock settings. I have a p2020 board and can take some scope
measurements next week to prove this. I think something should be
modified to address this.
On Tue, Nov 25, 2014 at 5:41 PM, Scott Wood <scottwood@freescale.com> wrote:
> On Tue, 2014-11-25 at 19:13 +0100, Wolfram Sang wrote:
>> On Mon, Nov 17, 2014 at 07:28:03PM -0600, Scott Wood wrote:
>> > On Fri, 2014-11-14 at 09:28 +0100, Wolfram Sang wrote:
>> > > > >
>> > > > > If we're going to change the device tree I'd rather just add a property
>> > > > > to say what the prescaler is.
>> > > >
>> > > > We would however, leave the boards' device trees that use things like
>> > > > "fsl,mpc8543-i2c" as is and introduce the prescaler for the others requiring it.
>> > > >
>> > > >
>> > > > Now the drawback is that the driver would require a change, to parse this
>> > > > prescaler new prescaler property. Would this be OK from your point of view
>> > > > Wolfram ? If yes, I will send the patches for it.
>> > >
>> > > I don't think it is OK.
>> >
>> > Why?
>>
>> Because I thought it could be deduced. Then, a seperate property would
>> not be OK.
>>
>> > > I'd think it can be deduced from the compatible property.
>> >
>> > For almost all existing device trees it cannot be.
>>
>> Pity :( If we do introduce a new property, it should probably be
>> "clock-div". Grepping through binding documentation, that seems
>> accepted. We should ask DT maintainers, too, to be safe.
>>
>> > If you want something that will work without changing device trees,
>> > you'll need to use SVR to identify the SoC.
>>
>> The driver is doing that already, see mpc_i2c_get_sec_cfg_8xxx(). Dunno
>> if it makes sense to add to it for consistency reasons?
>
> That's not SVR, but sure. Better to avoid messing with existing device
> trees.
>
> -Scott
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
- Danielle Costantino
^ permalink raw reply
* [PATCH] i2c: mpc: add register documentation to Freescale I2C driver
From: Danielle Costantino @ 2014-11-29 21:58 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-i2c
i2c: mpc: add register documentation to Freescale I2C driver
return -ETIMEDOUT for all time-out error conditions and warn on
arbitration lost.
Signed-off-by: Danielle Costantino <danielle.costantino@gmail.com>
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 4c5d7d9..28d9245 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -36,26 +36,31 @@
#define MPC_I2C_CLOCK_LEGACY 0
#define MPC_I2C_CLOCK_PRESERVE (~0U)
-#define MPC_I2C_FDR 0x04
-#define MPC_I2C_CR 0x08
-#define MPC_I2C_SR 0x0c
-#define MPC_I2C_DR 0x10
-#define MPC_I2C_DFSRR 0x14
+#define MPC_I2C_ADR 0x00 /* I2C address register */
+#define MPC_I2C_FDR 0x04 /* I2C frequency divider register */
+#define MPC_I2C_CR 0x08 /* I2C control register */
+#define MPC_I2C_SR 0x0C /* I2C status register */
+#define MPC_I2C_DR 0x10 /* I2C data register */
+#define MPC_I2C_DFSRR 0x14 /* I2C digital filter sampling rate
register */
-#define CCR_MEN 0x80
-#define CCR_MIEN 0x40
-#define CCR_MSTA 0x20
-#define CCR_MTX 0x10
-#define CCR_TXAK 0x08
-#define CCR_RSTA 0x04
+/* I2C Control Register (MPC_I2C_CR): */
+#define CCR_MEN 0x80 /* Module enable */
+#define CCR_MIEN 0x40 /* Module interrupt enable */
+#define CCR_MSTA 0x20 /* Master/slave mode START */
+#define CCR_MTX 0x10 /* Transmit/receive mode select */
+#define CCR_TXAK 0x08 /* Transfer acknowledge */
+#define CCR_RSTA 0x04 /* Repeated START */
+#define CCR_BCST 0x01 /* Broadcast */
-#define CSR_MCF 0x80
-#define CSR_MAAS 0x40
-#define CSR_MBB 0x20
-#define CSR_MAL 0x10
-#define CSR_SRW 0x04
-#define CSR_MIF 0x02
-#define CSR_RXAK 0x01
+/* I2C Status Register (MPC_I2C_SR): */
+#define CSR_MCF 0x80 /* Data transfer */
+#define CSR_MAAS 0x40 /* Addressed as a slave */
+#define CSR_MBB 0x20 /* Bus busy */
+#define CSR_MAL 0x10 /* Arbitration lost */
+#define CSR_BCSTM 0x08 /* Broadcast match */
+#define CSR_SRW 0x04 /* Slave read/write */
+#define CSR_MIF 0x02 /* Module interrupt */
+#define CSR_RXAK 0x01 /* Received acknowledge */
struct mpc_i2c {
struct device *dev;
@@ -158,12 +163,12 @@
return result;
if (!(cmd_err & CSR_MCF)) {
- dev_dbg(i2c->dev, "unfinished\n");
+ dev_warn(i2c->dev, "unfinished\n");
return -EIO;
}
if (cmd_err & CSR_MAL) {
- dev_dbg(i2c->dev, "MAL\n");
+ dev_err(i2c->dev, "Arbitration lost\n");
return -EAGAIN;
}
@@ -554,7 +559,7 @@
i2c->base + MPC_I2C_SR);
mpc_i2c_fixup(i2c);
}
- return -EIO;
+ return -ETIMEDOUT;
}
schedule();
}
@@ -590,7 +595,7 @@
i2c->base + MPC_I2C_SR);
mpc_i2c_fixup(i2c);
}
- return -EIO;
+ return -ETIMEDOUT;
}
cond_resched();
}
^ permalink raw reply related
* Re: powerpc/book3s: Fix flush_tlb cpu_spec hook to take a generic argument.
From: Michael Ellerman @ 2014-11-28 22:38 UTC (permalink / raw)
To: Mahesh Salgaonkar, linuxppc-dev, Paul Mackerras,
Benjamin Herrenschmidt
In-Reply-To: <20140923035330.6097.43515.stgit@mars>
On Tue, 2014-23-09 at 03:53:54 UTC, Mahesh Salgaonkar wrote:
> From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
>
> The flush_tlb hook in cpu_spec was introduced as a generic function hook
> to invalidate TLBs. But the current implementation of flush_tlb hook
> takes IS (invalidation selector) as an argument which is architecture
> dependent. Hence, It is not right to have a generic routine where caller
> has to pass non-generic argument.
>
> This patch fixes this and makes flush_tlb hook as high level API.
>
> The old code used to call flush_tlb hook with IS=0 (single page) resulting
> partial invalidation of TLBs which is not right. This fix now makes
> sure that whole TLB is invalidated to be able to successfully recover from
> TLB and ERAT errors.
Which old code? You mean the MCE code I think. That's a bug fix, so it should
be a separate patch.
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index daa5af9..ae3e74f 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -100,7 +100,7 @@ struct cpu_spec {
> /*
> * Processor specific routine to flush tlbs.
> */
> - void (*flush_tlb)(unsigned long inval_selector);
> + void (*flush_tlb)(unsigned int action);
>
> };
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index d765144..068ac8b 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -112,6 +112,11 @@
> #define TLBIEL_INVAL_SET_SHIFT 12
>
> #define POWER7_TLB_SETS 128 /* # sets in POWER7 TLB */
> +#define POWER8_TLB_SETS 512 /* # sets in POWER8 TLB */
> +
> +/* TLB flush actions. Used as argument to cpu_spec.flush_tlb() hook */
> +#define FLUSH_TLB_ALL 0 /* invalidate all TLBs */
> +#define FLUSH_TLB_LPID 1 /* invalidate TLBs for current LPID */
Now that these are generic actions then they should go in cputable.h with the
flush hook.
> diff --git a/arch/powerpc/kernel/cpu_setup_power.S b/arch/powerpc/kernel/cpu_setup_power.S
> index 4673353..9c9b741 100644
> --- a/arch/powerpc/kernel/cpu_setup_power.S
> +++ b/arch/powerpc/kernel/cpu_setup_power.S
> @@ -137,15 +137,11 @@ __init_HFSCR:
> /*
> * Clear the TLB using the specified IS form of tlbiel instruction
> * (invalidate by congruence class). P7 has 128 CCs., P8 has 512.
> - *
> - * r3 = IS field
> */
> __init_tlb_power7:
> - li r3,0xc00 /* IS field = 0b11 */
> -_GLOBAL(__flush_tlb_power7)
> li r6,128
> mtctr r6
> - mr r7,r3 /* IS field */
> + li r7,0xc00 /* IS field = 0b11 */
> ptesync
> 2: tlbiel r7
> addi r7,r7,0x1000
So the current version is:
_GLOBAL(__flush_tlb_power7)
li r6,128
mtctr r6
mr r7,r3 /* IS field */
ptesync
2: tlbiel r7
addi r7,r7,0x1000
bdnz 2b
ptesync
1: blr
ie. a loop preceeded and followed by ptesync.
Your new version is:
> +static void _flush_tlb(uint32_t tlb_set, unsigned long inval_selector)
> +{
> + unsigned long i, rb;
> +
> + rb = inval_selector;
> + for (i = 0; i < tlb_set; i++) {
> + asm volatile("tlbiel %0" : : "r" (rb));
> + rb += 1 << TLBIEL_INVAL_SET_SHIFT;
> + }
> +}
ie. no ptesyncs at all.
But there's no mention of that in the changelog. You need to explain why it is
OK to drop the ptesyncs.
> +/*
> + * Generic routine to flush TLB on power7. This routine is used as
> + * flush_tlb hook in cpu_spec for Power7 processor.
> + *
> + * action => FLUSH_TLB_ALL: Invalidate all TLBs.
> + * FLUSH_TLB_LPID: Invalidate TLB for current LPID.
> + */
> +void __flush_tlb_power7(unsigned int action)
> +{
> + switch (action) {
> + case FLUSH_TLB_ALL:
> + _flush_tlb(POWER7_TLB_SETS, TLBIEL_INVAL_SET);
> + break;
> + case FLUSH_TLB_LPID:
> + _flush_tlb(POWER7_TLB_SETS, TLBIEL_INVAL_SET_LPID);
> + break;
> + default:
> + break;
> + }
> +}
> +
> +/*
> + * Generic routine to flush TLB on power8. This routine is used as
> + * flush_tlb hook in cpu_spec for power8 processor.
> + *
> + * action => FLUSH_TLB_ALL: Invalidate all TLBs.
> + * FLUSH_TLB_LPID: Invalidate TLB for current LPID.
> + */
> +void __flush_tlb_power8(unsigned int action)
> +{
> + switch (action) {
> + case FLUSH_TLB_ALL:
> + _flush_tlb(POWER8_TLB_SETS, TLBIEL_INVAL_SET);
> + break;
> + case FLUSH_TLB_LPID:
> + _flush_tlb(POWER8_TLB_SETS, TLBIEL_INVAL_SET_LPID);
> + break;
> + default:
> + break;
> + }
> +}
How about this:
void flush_tlb_206(unsigned num_sets, unsigned int action)
{
unsigned long rb;
int i;
switch (action) {
case FLUSH_TLB_ALL:
rb = TLBIEL_INVAL_SET;
break;
case FLUSH_TLB_LPID:
rb = TLBIEL_INVAL_SET_LPID;
break;
default:
BUG();
}
for (i = 0; i < num_sets; i++) {
asm volatile("tlbiel %0" : : "r" (rb));
rb += 1 << TLBIEL_INVAL_SET_SHIFT;
}
}
void flush_tlb_power8(unsigned int action)
{
flush_tlb_206(POWER8_TLB_SETS, action);
}
void flush_tlb_power7(unsigned int action)
{
flush_tlb_206(POWER7_TLB_SETS, action);
}
cheers
^ permalink raw reply
* Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
From: Segher Boessenkool @ 2014-11-28 16:00 UTC (permalink / raw)
To: Madhavan Srinivasan; +Cc: rusty, paulus, anton, linuxppc-dev
In-Reply-To: <5477E492.4000009@linux.vnet.ibm.com>
On Fri, Nov 28, 2014 at 08:27:22AM +0530, Madhavan Srinivasan wrote:
> > Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5,
> > and it likes to use it very much, it might be more convenient to
> > use e.g. CR1 (which is allocated almost last, only before CR0).
> >
> No. I did not try it with GCC5.0 But I did force kernel compilation with
> fixed-cr5 which should make GCC avoid using CR5. But i will try that today.
It should work just fine, but testing is always useful, because, you know,
"should". Thanks.
Segher
^ permalink raw reply
* Re: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
From: Segher Boessenkool @ 2014-11-28 15:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, rusty, Madhavan Srinivasan, paulus, anton
In-Reply-To: <1417139935.2852.19.camel@kernel.crashing.org>
On Fri, Nov 28, 2014 at 12:58:55PM +1100, Benjamin Herrenschmidt wrote:
> > Have you tested this with (upcoming) GCC 5.0? GCC now uses CR5,
> > and it likes to use it very much, it might be more convenient to
> > use e.g. CR1 (which is allocated almost last, only before CR0).
>
> We use CR1 all over the place in your asm code. Any other suggestion ?
>
> What's the damage of -ffixed-cr5 on gcc5 ? won't it just use CR4 or 6
> instead ?
Oh, it will work fine. Not using CR5 would be more convenient so that
the register allocation for most code would not change when you use or
not use -ffixed-cr5, making code easier to read. But your point about
asm code already using the other CR fields makes CR5 a better choice
actually, because people avoided it (because the compiler did) :-)
Segher
^ permalink raw reply
* Re: [PATCH] kbuild: Fix make help-<board series> on powerpc
From: Michal Marek @ 2014-11-28 15:40 UTC (permalink / raw)
To: linux-kbuild; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1417179145-30789-1-git-send-email-mmarek@suse.cz>
On 2014-11-28 13:52, Michal Marek wrote:
> make ARCH=powerpc help-<board series> should not require a cofigured
> source tree. Also, sort the boards in the output.
I added this to kbuild.git#kbuild.
Michal
^ permalink raw reply
* [PATCH] kbuild: Fix make help-<board series> on powerpc
From: Michal Marek @ 2014-11-28 12:52 UTC (permalink / raw)
To: linux-kbuild; +Cc: linuxppc-dev, linux-kernel
make ARCH=powerpc help-<board series> should not require a cofigured
source tree. Also, sort the boards in the output.
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
Sorry for the double post to the ppc mailing list. The first version got
rejected by the vger spam filter.
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 88b7fa5..0cd4e14 100644
--- a/Makefile
+++ b/Makefile
@@ -482,7 +482,7 @@ asm-generic:
version_h := include/generated/uapi/linux/version.h
no-dot-config-targets := clean mrproper distclean \
- cscope gtags TAGS tags help %docs check% coccicheck \
+ cscope gtags TAGS tags help% %docs check% coccicheck \
$(version_h) headers_% archheaders archscripts \
kernelversion %src-pkg
@@ -1323,7 +1323,7 @@ help-board-dirs := $(addprefix help-,$(board-dirs))
help-boards: $(help-board-dirs)
-boards-per-dir = $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig))
+boards-per-dir = $(sort $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig)))
$(help-board-dirs): help-%:
@echo 'Architecture specific targets ($(SRCARCH) $*):'
--
2.1.2
^ permalink raw reply related
* [PATCH] kbuild: Fix make help-XXX on powerpc
From: Michal Marek @ 2014-11-28 12:42 UTC (permalink / raw)
To: linux-kbuild; +Cc: linuxppc-dev, linux-kernel
make ARCH=powerpc help-<board series> should not require a cofigured
source tree. Also, sort the boards in the output.
Signed-off-by: Michal Marek <mmarek@suse.cz>
---
Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 88b7fa5..0cd4e14 100644
--- a/Makefile
+++ b/Makefile
@@ -482,7 +482,7 @@ asm-generic:
version_h := include/generated/uapi/linux/version.h
no-dot-config-targets := clean mrproper distclean \
- cscope gtags TAGS tags help %docs check% coccicheck \
+ cscope gtags TAGS tags help% %docs check% coccicheck \
$(version_h) headers_% archheaders archscripts \
kernelversion %src-pkg
@@ -1323,7 +1323,7 @@ help-board-dirs := $(addprefix help-,$(board-dirs))
help-boards: $(help-board-dirs)
-boards-per-dir = $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig))
+boards-per-dir = $(sort $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig)))
$(help-board-dirs): help-%:
@echo 'Architecture specific targets ($(SRCARCH) $*):'
--
2.1.2
^ permalink raw reply related
* RE: [RFC PATCH 1/2]powerpc: foundation code to handle CR5 for local_t
From: David Laight @ 2014-11-28 10:53 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt', Madhavan Srinivasan
Cc: linuxppc-dev@lists.ozlabs.org, rusty@rustcorp.com.au,
paulus@samba.org, anton@samba.org
In-Reply-To: <1417144874.2852.21.camel@au1.ibm.com>
RnJvbTogQmVuamFtaW4gSGVycmVuc2NobWlkdA0KPiBPbiBGcmksIDIwMTQtMTEtMjggYXQgMDg6
NDUgKzA1MzAsIE1hZGhhdmFuIFNyaW5pdmFzYW4gd3JvdGU6DQo+ID4gPiBDYW4ndCB3ZSBqdXN0
IHVuY29uZGl0aW9uYWxseSBjbGVhciBhdCBhcyBsb25nIGFzIHdlIGRvIHRoYXQgYWZ0ZXIgd2Un
dmUNCj4gPiA+IHNhdmVkIGl0ID8gSW4gdGhhdCBjYXNlLCBpdCdzIGp1c3QgYSBtYXR0ZXIgZm9y
IHRoZSBmaXh1cCBjb2RlIHRvIGNoZWNrDQo+ID4gPiB0aGUgc2F2ZWQgdmVyc2lvbiByYXRoZXIg
dGhhbiB0aGUgYWN0dWFsIENSLi4NCj4gPiA+DQo+ID4gSSB1c2UgQ1IgYml0IHNldHRpbmcgaW4g
dGhlIGludGVycnVwdCByZXR1cm4gcGF0aCB0byBlbnRlciB0aGUgZml4dXANCj4gPiBzZWN0aW9u
IHNlYXJjaC4gSWYgd2UgdW5jb25kaXRpb25hbGx5IGNsZWFyIGl0LCB3ZSB3aWxsIGhhdmUgdG8g
ZW50ZXINCj4gPiB0aGUgZml4dXAgc2VjdGlvbiBmb3IgZXZlcnkga2VybmVsIHJldHVybiBuaXAg
cmlnaHQ/DQo+IA0KPiBBcyBJIHNhaWQgYWJvdmUuIENhbid0IHdlIGxvb2sgYXQgdGhlIHNhdmVk
IHZlcnNpb24gPw0KPiANCj4gSUUuDQo+IA0KPiAgLSBPbiBpbnRlcnJ1cHQgZW50cnk6DQo+IA0K
PiAJKiBTYXZlIENSIHRvIENDUihyMSkNCj4gCSogY2xlYXIgQ1I1DQo+IA0KPiAgLSBPbiBleGl0
DQo+IA0KPiAJKiBDaGVjayBDQ1IocjEpJ3MgQ1I1IGZpZWxkDQo+IAkqIHJlc3RvcmUgQ1INCg0K
QWN0dWFsbHkgdGhlcmUgaXMgbm8gcmVhbCByZWFzb24gd2h5IHRoZSAnZml4dXAnIGNhbid0IGJl
IGRvbmUNCmR1cmluZyBpbnRlcnJ1cHQgZW50cnkuDQoNCglEYXZpZA0KDQo=
^ permalink raw reply
* [PATCH] Documentation: bindings: net: DPAA corenet binding document
From: Madalin Bucur @ 2014-11-28 10:10 UTC (permalink / raw)
To: devicetree, linuxppc-dev, netdev
Cc: scottwood, Igal.Liberman, Emilian.Medve, Madalin Bucur
Add the device tree binding document for the DPAA corenet node
and DPAA Ethernet nodes.
Signed-off-by: Madalin Bucur <madalin.bucur@freescale.com>
---
Documentation/devicetree/bindings/net/fsl-dpaa.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/fsl-dpaa.txt
diff --git a/Documentation/devicetree/bindings/net/fsl-dpaa.txt b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
new file mode 100644
index 0000000..822c668
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fsl-dpaa.txt
@@ -0,0 +1,31 @@
+*DPAA corenet
+
+The corenet bus containing all DPAA Ethernet nodes.
+
+Required property
+ - compatible: string property. Must include "fsl,dpaa". Can include
+ also "fsl,<SoC>-dpaa".
+
+Example:
+
+fsl,dpaa {
+ compatible = "fsl,p4080-dpaa", "fsl,dpaa";
+};
+
+*DPAA Ethernet
+
+DPAA Ethernet implements an Ethernet interface on top of the functionality
+offered by the DPAA accelerators: QMan, BMan, FMan. It contains a reference
+to the FMan MAC node used (dTSEC, TGEC, MEMAC). This construct is used by
+u-boot for the boot-time device tree fix-up.
+
+Required properties
+ - compatible: standard string property. Must include "fsl,dpa-ethernet".
+ - fsl,fman-mac: phandle that references a node describing the used DPAA MAC.
+
+Example:
+
+ethernet0 {
+ compatible = "fsl,dpa-ethernet";
+ fsl,fman-mac = <&enet0>;
+};
--
1.7.11.7
^ permalink raw reply related
* RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation
From: David Laight @ 2014-11-28 10:09 UTC (permalink / raw)
To: 'Madhavan Srinivasan', mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, rusty@rustcorp.com.au,
paulus@samba.org, anton@samba.org
In-Reply-To: <547831DC.6000703@linux.vnet.ibm.com>
RnJvbTogTWFkaGF2YW4gU3Jpbml2YXNhbg0KPiBPbiBUaHVyc2RheSAyNyBOb3ZlbWJlciAyMDE0
IDA3OjM1IFBNLCBEYXZpZCBMYWlnaHQgd3JvdGU6DQo+ID4gRnJvbTogTWFkaGF2YW4gU3Jpbml2
YXNhbg0KPiA+PiBUaGlzIHBhdGNoc2V0IGNyZWF0ZSB0aGUgaW5mcmFzdHJ1Y3R1cmUgdG8gaGFu
ZGxlIHRoZSBDUiBiYXNlZA0KPiA+PiBsb2NhbF8qIGF0b21pYyBvcGVyYXRpb25zLiBMb2NhbCBh
dG9taWMgb3BlcmF0aW9ucyBhcmUgZmFzdA0KPiA+PiBhbmQgaGlnaGx5IHJlZW50cmFudCBwZXIg
Q1BVIGNvdW50ZXJzLiAgVXNlZCBmb3IgcGVyY3B1DQo+ID4+IHZhcmlhYmxlIHVwZGF0ZXMuIExv
Y2FsIGF0b21pYyBvcGVyYXRpb25zIG9ubHkgZ3VhcmFudGVlDQo+ID4+IHZhcmlhYmxlIG1vZGlm
aWNhdGlvbiBhdG9taWNpdHkgd3J0IHRoZSBDUFUgd2hpY2ggb3ducyB0aGUNCj4gPj4gZGF0YSBh
bmQgdGhlc2UgbmVlZHMgdG8gYmUgZXhlY3V0ZWQgaW4gYSBwcmVlbXB0aW9uIHNhZmUgd2F5Lg0K
PiA+DQo+ID4gVGhlc2UgYXJlIHVzdWFsbHkgY2FsbGVkICdyZXN0YXJ0YWJsZSBhdG9taWMgc2Vx
dWVuY2VzIChSQVMpJy4NCj4gPg0KPiA+PiBIZXJlIGlzIHRoZSBkZXNpZ24gb2YgdGhlIGZpcnN0
IHBhdGNoLiBTaW5jZSBsb2NhbF8qIG9wZXJhdGlvbnMNCj4gPj4gYXJlIG9ubHkgbmVlZCB0byBi
ZSBhdG9taWMgdG8gaW50ZXJydXB0cyAoSUlVQyksIHBhdGNoIHVzZXMNCj4gPj4gb25lIG9mIHRo
ZSBDb25kaXRpb24gUmVnaXN0ZXIgKENSKSBmaWVsZHMgYXMgYSBmbGFnIHZhcmlhYmxlLiBXaGVu
DQo+ID4+IGVudGVyaW5nIHRoZSBsb2NhbF8qLCBzcGVjaWZpYyBiaXQgaW4gdGhlIENSNSBmaWVs
ZCBpcyBzZXQNCj4gPj4gYW5kIG9uIGV4aXQsIGJpdCBpcyBjbGVhcmVkLiBDUiBiaXQgY2hlY2tp
bmcgaXMgZG9uZSBpbiB0aGUNCj4gPj4gaW50ZXJydXB0IHJldHVybiBwYXRoLiBJZiBDUjVbRVFd
IGJpdCBzZXQgYW5kIGlmIHdlIHJldHVybg0KPiA+PiB0byBrZXJuZWwsIHdlIHJlc2V0IHRvIHN0
YXJ0IG9mIGxvY2FsXyogb3BlcmF0aW9uLg0KPiA+DQo+ID4gSSBkb24ndCBjbGFpbSB0byBiZSBh
YmxlIHRvIHJlYWQgcHBjIGFzc2VtYmxlci4NCj4gPiBCdXQgSSBjYW4ndCBzZWUgdGhlIGNvZGUg
dGhhdCBjbGVhcnMgQ1I1W0VRXSBmb3IgdGhlIGR1cmF0aW9uDQo+ID4gb2YgdGhlIElTUi4NCj4g
SSB1c2UgY3JjbHIgaW5zdHJ1Y3Rpb24gYXQgdGhlIGVuZCBvZiB0aGUgY29kZSBibG9jayB0byBj
bGVhciB0aGUgYml0Lg0KPiANCj4gPiBXaXRob3V0IGl0IGEgbmVzdGVkIGludGVycnVwdCB3aWxs
IGdvIHRocm91Z2ggdW53YW50ZWQgcGF0aHMuDQoNClRoYXQgY3JjbHIgbG9va3MgdG8gYmUgaW4g
dGhlIElTUiBleGl0IHBhdGgsIHlvdSBuZWVkIG9uZSBpbiB0aGUNCmlzciBlbnRyeSBwYXRoLg0K
DQo+ID4NCj4gPiBUaGVyZSBhcmUgYWxzbyBhIGxvdCBvZiAnbWFnaWMnIGNvbnN0YW50cyBpbiB0
aGF0IGFzc2VtYmx5IGNvZGUuDQo+ID4NCj4gQWxsIHRoZXNlIGNvbnN0YW50cyBhcmUgZGVmaW5l
IGluIGFzbS9wcGMtb3Bjb2RlLmgNCg0KSSB3YXMgdGhpbmtpbmcgb2YgdGhlIGxpbmVzIGxpa2U6
DQorCW9yaQlyMyxyMywxNjM4NA0KVGhpcyBvbmUgcHJvYmFibHkgZGVzZXJ2ZXMgYSBjb21tZW50
IC0gb3Igc29tZXRoaW5nDQorIjM6IglQUEM0MDVfRVJSNzcoMCwlMikNCg0KPiA+IEkgYWxzbyB3
b25kZXIgaWYgaXQgaXMgcG9zc2libGUgdG8gaW5zcGVjdCB0aGUgaW50ZXJydXB0ZWQNCj4gPiBj
b2RlIHRvIGRldGVybWluZSB0aGUgc3RhcnQvZW5kIG9mIHRoZSBSQVMgYmxvY2suDQo+ID4gKEVh
c2llc3QgaWYgeW91IGFzc3VtZSB0aGF0IHRoZXJlIGlzIGEgc2luZ2xlICd3cml0ZScgaW5zdHJ1
Y3Rpb24NCj4gPiBhcyB0aGUgbGFzdCBlbnRyeSBpbiB0aGUgYmxvY2suKQ0KPiA+DQo+IFNvIGVh
Y2ggbG9jYWxfKiBmdW5jdGlvbiBhbHNvIGhhdmUgY29kZSBpbiB0aGUgX19leF90YWJsZSBzZWN0
aW9uLiBJSVVDLA0KPiBfX2V4X3RhYmxlIGNvbnRhaW5zIHR3byBhZGRyZXNzLiBTbyBpZiB0aGUg
cmV0dXJuIGFkZHJlc3MgZm91bmQgaW4gdGhlDQo+IGZpcnN0IGNvbHVtbiBvZiB0aGUgX2V4X3Rh
YmxlLCB1c2UgdGhlIGNvcnJlc3BvbmRpbmcgYWRkcmVzcyBpbiB0aGUNCj4gc2Vjb25kIGNvbHVt
biB0byBjb250aW51ZSBmcm9tLg0KDQpUaGF0IHJlYWxseSBkb2Vzbid0IHNjYWxlLg0KSSBkb24n
dCBrbm93IGhvdyBtYW55IDEwMDAgYWRkcmVzcyBwYWlycyB5b3UgdGFibGUgd2lsbCBoYXZlIChh
bmQgdGhlDQpvbmVzIGluIGVhY2ggbG9hZGFibGUgbW9kdWxlKSwgYnV0IHRoZSBzZWFyY2ggaXNu
J3QgZ29pbmcgdG8gYmUgY2hlYXAuDQoNCklmIHRoZXNlIHNlcXVlbmNlcyBhcmUgcmVzdGFydGFi
bGUgdGhlbiB0aGV5IGNhbiBvbmx5IGhhdmUgb25lIHdyaXRlDQp0byBtZW1vcnkuDQoNCkdpdmVu
IHlvdXI6DQo+IFRoaXMgcGF0Y2ggcmUtd3JpdGUgdGhlIGN1cnJlbnQgbG9jYWxfKiBmdW5jdGlv
bnMgdG8gQ1I1IGJhc2VkIG9uZS4NCj4gQmFzZSBmbG93IGZvciBlYWNoIGZ1bmN0aW9uIGlzIA0K
PiANCj4gew0KPiAJc2V0IGNyNShlcSkNCj4gCWxvYWQNCj4gCS4uDQo+IAlzdG9yZQ0KPiAJY2xl
YXIgY3I1KGVxKQ0KPiB9DQoNCk9uIElTUiBlbnRyeToNCklmIGFuIElTUiBkZXRlY3RzIGNyNShl
cSkgc2V0IHRoZW4gbG9vayBhdCB0aGUgcmV0dXJuZWQgdG8gaW5zdHJ1Y3Rpb24uDQpJZiBpdCBp
cyAnY2xlYXIgY3I1KGVxKScgZG8gbm90aGluZy4NCk90aGVyd2lzZSByZWFkIGJhY2t3YXJkcyB0
aHJvdWdoIHRoZSBjb2RlIChmb3IgYSBtYXggb2YgKHNheSkgMTYgaW5zdHJ1Y3Rpb25zKQ0Kc2Vh
cmNoaW5nIGZvciB0aGUgJ3NldCBjcjUoZXEpJyBhbmQgY2hhbmdlIHRoZSByZXR1cm4gYWRkcmVz
cyB0byBiZSB0aGF0DQpvZiB0aGUgaW5zdHJ1Y3Rpb24gZm9sbG93aW5nIHRoZSAnc2V0IGNyNShl
cSknLg0KSW4gYWxsIGNhc2VzIGNsZWFyIGNyNShlcSkgZm9yIHRoZSBJU1IgaXRzZWxmIChsZWF2
ZSB0aGUgc2F2ZWQgdmFsdWUgdW5jaGFuZ2VkKS4NCg0KVGhlIHlvdSBkb24ndCBuZWVkIGEgdGFi
bGUgb2YgZmF1bHQgbG9jYXRpb25zLg0KDQoJRGF2aWQNCg0K
^ permalink raw reply
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