Re: [PATCH 33/44] avr32: atngw100: Register with kernel poweroff handler
Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote:
Register with kernel poweroff handler instead of setting pm_power_off
directly.
Cc: Haavard Skinnemoen hskinnem...@gmail.com
Cc: Hans-Christian Egtvedt egtv...@samfundet.no
Signed-off-by: Guenter Roeck li...@roeck-us.net
Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no
---
arch/avr32/boards/atngw100/mrmt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/avr32/boards/atngw100/mrmt.c
b/arch/avr32/boards/atngw100/mrmt.c
index 91146b4..54d0c27 100644
--- a/arch/avr32/boards/atngw100/mrmt.c
+++ b/arch/avr32/boards/atngw100/mrmt.c
@@ -274,7 +274,7 @@ static int __init mrmt1_init(void)
{
gpio_set_value( PIN_PWR_ON, 1 );/* Ensure PWR_ON is enabled */
- pm_power_off = mrmt_power_off;
+ register_poweroff_handler_simple(mrmt_power_off, 128);
/* Setup USARTS (other than console) */
at32_map_usart(2, 1, 0);/* USART 2: /dev/ttyS1, RMT1:DB9M */
--
mvh
Hans-Christian Egtvedt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Replace cc constraint in inline assembly with cr0
On Sat, Nov 01, 2014 at 11:42:51AM +1100, Anton Blanchard wrote: Our inline assembly only clobbers the first condition register field, but we mark all of them as being clobbered. No, we don't. cc has been an alias for cr0 for over twenty two and a half years now; it has never changed meaning. This is an LLVM bug. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
ping On 10/31/14, Denis Kirjanov kirja...@gmail.com wrote: On 10/30/14, Alexei Starovoitov alexei.starovoi...@gmail.com wrote: On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov k...@linux-powerpc.org wrote: Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load skb-pkt_type field. Before: [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS After: [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS if you'd only quoted #12, it would all make sense ;) but #11 test is not using PKTTYPE. So your patch shouldn't make a difference. Are these numbers with JIT on and off? Right. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Regards, Denis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 33/44] avr32: atngw100: Register with kernel poweroff handler
On 11/01/2014 03:16 AM, Hans-Christian Egtvedt wrote: Around Mon 06 Oct 2014 22:28:35 -0700 or thereabout, Guenter Roeck wrote: Register with kernel poweroff handler instead of setting pm_power_off directly. Cc: Haavard Skinnemoen hskinnem...@gmail.com Cc: Hans-Christian Egtvedt egtv...@samfundet.no Signed-off-by: Guenter Roeck li...@roeck-us.net Acked-by: Hans-Christian Egtvedt egtv...@samfundet.no Thanks! Guenter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
David, you need a feedback from other guys to apply this patch, right? Alexei wanted some output before/after the patch. Michael Ellerman wanted the explanation what a BPF_ANC | SKF_AD_PKTTYPE means. So I'm waiting the ack/nack from them... On 11/1/14, David Miller da...@davemloft.net wrote: From: Denis Kirjanov k...@linux-powerpc.org Date: Sat, 1 Nov 2014 20:19:09 +0400 ping What specifically are you waiting for? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov k...@linux-powerpc.org Date: Sat, 1 Nov 2014 20:19:09 +0400 ping What specifically are you waiting for? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov k...@linux-powerpc.org Date: Sat, 1 Nov 2014 21:49:27 +0400 David, you need a feedback from other guys to apply this patch, right? Alexei wanted some output before/after the patch. Michael Ellerman wanted the explanation what a BPF_ANC | SKF_AD_PKTTYPE means. So I'm waiting the ack/nack from them... I don't really think performance metrics are necessary just for adding SKF_AD_PKTTYPE support, that's sort of an over the top requirement if you ask me. It's pretty obvious that we should support as many operations as possible to each JIT, because all of program has to do is use that unsupported opcode and then we have none of that program being JIT'd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Date: Wed, 29 Oct 2014 13:49:44 +0530 +/* + * Some architectures requires a hugepage directory format that is + * required to support multiple hugepage sizes. For example + * a4fe3ce7699bfe1bd88f816b55d42d8fe1dac655 introduced the same + * on powerpc. This allows for a more flexible hugepage pagetable + * layout. + */ Please don't put commit IDs into the actual code. If that commit gets backported to -stable or another tree, then this comment will send someone on a wild goose chase. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
On 11/01/2014 07:00 PM, David Miller wrote: From: Denis Kirjanov k...@linux-powerpc.org Date: Sat, 1 Nov 2014 21:49:27 +0400 David, you need a feedback from other guys to apply this patch, right? Alexei wanted some output before/after the patch. Michael Ellerman wanted the explanation what a BPF_ANC | SKF_AD_PKTTYPE means. The BPF_ANC | SKF_AD_PKTTYPE case means that this is an ancillary operation aka BPF extension which loads the value of skb-pkt_type into the accumulator. A similar transformation, that is, from BPF into eBPF insns can be found in convert_bpf_extensions() in the SKF_AD_PKTTYPE case, or commit 709f6c58d4dc (sparc: bpf_jit: add SKF_AD_PKTTYPE support to JIT) that recently enabled the same in sparc. So I'm waiting the ack/nack from them... I don't really think performance metrics are necessary just for adding SKF_AD_PKTTYPE support, that's sort of an over the top requirement if you ask me. Right, lib/test_bpf.c actually brings the quoted output w/ numbers for free. I think the important point was that the 'After:' case with ``echo 1 /proc/sys/net/core/bpf_jit_enable'' runs through for that test case, which has been shown here. It's pretty obvious that we should support as many operations as possible to each JIT, because all of program has to do is use that unsupported opcode and then we have none of that program being JIT'd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
On 10/31/2014 07:09 AM, Denis Kirjanov wrote: On 10/30/14, Alexei Starovoitov alexei.starovoi...@gmail.com wrote: On Wed, Oct 29, 2014 at 11:12 PM, Denis Kirjanov k...@linux-powerpc.org wrote: Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load skb-pkt_type field. Before: [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS After: [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS if you'd only quoted #12, it would all make sense ;) but #11 test is not using PKTTYPE. So your patch shouldn't make a difference. Are these numbers with JIT on and off? Right. Ok. Please mention this in future log messages, as it was not quite clear that before was actually with JIT off, and after was with JIT on. One could have read it that actually both cases were with JIT on, and thus the inconsistent result for LD_IND_NET is a bit confusing since you've quoted it here as well. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Date: Wed, 29 Oct 2014 13:49:44 +0530 Update generic gup implementation with powerpc specific details. On powerpc at pmd level we can have hugepte, normal pmd pointer or a pointer to the hugepage directory. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- Changes from V3: * Drop arm and arm64 changes * Add hugepte assumption to the function Wait, what are you doing here? You can't assume that a pmd is something you can just go: __pte(pmd_val(x)) with. Not at all. You have to use the correct pmd_*() accessors at all times on this object. Platforms can encode PMDs however they like. In fact, on sparc64, we used to have 32-bit PMDs with a special encoding for huge PMDs that looked nothing at all like a 64-bit PTE. Please code this in a portable manner to support the powerpc facilities, don't add assumptions that are not necessarily universally true. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
