Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan Date: Tue, 31 Mar 2015 14:06:42 -0400 > Having bravely said that.. > > the IB team informs me that they see a 10% degradation using > the spin_lock as opposed to the trylock. > > one path going forward is to continue processing this patch-set > as is. I can investigate this further, and later revise the spin_lock > to the trylock, after we are certain that it is good/necessary. > > thoughts? Let's address the trylock vs. spin_lock thing later and use plain spin_lock for now. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan Date: Tue, 31 Mar 2015 21:08:18 -0400 > I'm starting to wonder if some approximation of dma premapped > buffers may be needed. Doing a map/unmap on each packet is expensive. It's much more amortized with smart buffering strategies, which are common on current generation networking cards. There you only eat one map/unmap per "PAGE_SIZE / rx_pkt_size". Maybe the infiniband stuff is doing things very suboptimally, and actually with that subsystem and drivers absolutely nothing would surprise me. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] envctrl: Ignore orderly_poweroff return value
From: Joel Stanley Date: Wed, 1 Apr 2015 17:34:46 +1030 > orderly_poweroff() unconditionally returns 0, so remove the dead code > that checks the return value. > > A future patch will change the return type to void. > > Signed-off-by: Joel Stanley Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 RFC 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan Date: Thu, 2 Apr 2015 08:51:52 -0400 > do I need to resubmit this without the RFC tag? Perhaps I should > have dropped that some time ago. I want to hear from the powerpc folks whether they can positively adopt the new generic code or not. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v8 RFC 1/3] sparc: Break up monolithic iommu table/lock into finer graularity pools and lock
From: Sowmini Varadhan Date: Thu, 2 Apr 2015 17:54:53 -0400 > the other question that comes to my mind is: the whole lazy_flush > optimization probably works best when there is exactly one pool, > and no large pools. In most other cases, we'd end up doing a lazy_flush > when we wrap within our pool itself, losing the benefit of that > optimization. > > Given that the lazy_flush is mostly there to avoid regressions for > the older sun4u architectures (which have other hardware bottlenecks > anyway), and this code is rapidly getting messy, does it make sense > to constrain the lazy_flush check to only apply for the 1-pool, > no-large-pool case? I think it's better to have the multiple pools with more often global flushing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan Date: Thu, 9 Apr 2015 15:33:29 -0400 > v10: resend patchv9 without RFC tag, and a new mail Message-Id, > (previous non-RFC attempt did not show up on the patchwork queue?) Yes, if the patch is identical the patch postings hashes to the same value as the RFC ones, and therefore patchwork thinks it's a dup. I asked the patchwork maintainer to adjust this behavior in the future if he can. Nevertheless, thanks for posting, I was aware of the update. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/5] ibmveth: change rx buffer default allocation for CMO
The net-next tree is closed, so new feature submissions are not appropriate at this time. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 0/3] Generic IOMMU pooled allocator
From: Sowmini Varadhan Date: Thu, 9 Apr 2015 15:33:29 -0400 > Investigation of network performance on Sparc shows a high > degree of locking contention in the IOMMU allocator, and it > was noticed that the PowerPC code has a better locking model. > > This patch series tries to extract the generic parts of the > PowerPC code so that it can be shared across multiple PCI > devices and architectures. Series applied, thanks everyone for all the hard work! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)
From: Guenter Roeck Date: Sun, 19 Apr 2015 22:17:21 -0700 > The debug option is intended for all _other_ architectures, to > ensure that changes made for those don't break alpha/s390 > builds. alpha/s390 have ARCH_NEEDS_WEAK_PER_CPU and don't need the > debug option. Ironically this would not create a build failure for the architectures where this matters, because only powerpc has the like named percpu symbol. So it's not really meeting the stated objective in this case. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sparc64: Build failure due to commit f1600e549b94 (sparc: Make sparc64 use scalable lib/iommu-common.c functions)
From: Guenter Roeck Date: Mon, 20 Apr 2015 09:44:31 -0700 > On Mon, Apr 20, 2015 at 12:25:19PM -0400, David Miller wrote: >> From: Guenter Roeck >> Date: Sun, 19 Apr 2015 22:17:21 -0700 >> >> > The debug option is intended for all _other_ architectures, to >> > ensure that changes made for those don't break alpha/s390 >> > builds. alpha/s390 have ARCH_NEEDS_WEAK_PER_CPU and don't need the >> > debug option. >> >> Ironically this would not create a build failure for the architectures >> where this matters, because only powerpc has the like named percpu >> symbol. >> >> So it's not really meeting the stated objective in this case. > > Yes, that is correct; it can only find problems in non-architecture > code, and on the downside produces false positives and thus build errors > like this one. > > Which makes the fix a bit philosophical. Rename iommu_pool_hash in > iommu-common, or drop DEBUG_FORCE_WEAK_PER_CPU. I would rename > iommu_pool_hash, but that is just me. Ultimately, I don't really > care one way or another, as long as the problem gets fixed. If nightly builds of s390 and alpha, the two platforms where this matters, are being done as reported in this thread, then I really don't see the value in DEBUG_FORCE_WEAK_PER_CPU. But I guess that's a more involved longer-term discussion and I guess I'll apply Sowmini's patches for now. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2] ibmveth: Fix off-by-one error in ibmveth_change_mtu()
From: David Gibson Date: Thu, 23 Apr 2015 14:43:05 +1000 > AFAIK the PAPR document which defines the virtual device interface used by > the ibmveth driver doesn't specify a specific maximum MTU. So, in the > ibmveth driver, the maximum allowed MTU is determined by the maximum > allocated buffer size of 64k (corresponding to one page in the common case) > minus the per-buffer overhead IBMVETH_BUFF_OH (which has value 22 for 14 > bytes of ethernet header, plus 8 bytes for an opaque handle). > > This suggests a maximum allowable MTU of 65514 bytes, but in fact the > driver only permits a maximum MTU of 65513. This is because there is a < > instead of an <= in ibmveth_change_mtu(), which only permits an MTU which > is strictly smaller than the buffer size, rather than allowing the buffer > to be completely filled. > > This patch fixes the buglet. > > Signed-off-by: David Gibson > Acked-by: Thomas Falcon Applied, thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ehea: Fix memory hook reference counting crashes
From: Michael Ellerman
Date: Fri, 24 Apr 2015 15:52:32 +1000
> The recent commit to only register the EHEA memory hotplug hooks on
> adapter probe has a few problems.
>
> Firstly the reference counting is wrong for multiple adapters, in that
> the hooks are registered multiple times. Secondly the check in the tear
> down path is backward. Finally the error path doesn't decrement the
> count.
>
> The multiple registration of the hooks is the biggest problem, as it
> leads to oopses when the system is rebooted, and/or errors during memory
> hotplug, eg:
...
> Fixes: aa183323312d ("ehea: Register memory hotplug, reboot and crash hooks
> on adapter probe")
> Signed-off-by: Michael Ellerman
Applied, but using an atomic counter for this is really inappropriate
and is what lead to this bug in the first place.
You're not counting anything, because if you were, then you would be
decrementing this thing somewhere.
Rather, it's purely a boolean state saying "I did X". So it should be
a boolean, and no atomicity nor other special considerations are
needed for setting it to true.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v3 1/4] ibmveth: change rx buffer default allocation for CMO
From: Thomas Falcon Date: Wed, 29 Apr 2015 16:25:44 -0500 > This patch enables 64k rx buffer pools by default. If Cooperative > Memory Overcommitment (CMO) is enabled, the number of 64k buffers > is reduced to save memory. > > Cc: Brian King > Signed-off-by: Thomas Falcon Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v3 2/4] ibmveth: Add support for TSO
From: Thomas Falcon Date: Wed, 29 Apr 2015 16:25:45 -0500 > Add support for TSO. TSO is turned off by default and > must be enabled and configured by the user. The driver > version number is increased so that users can be sure > that they are using ibmveth with TSO support. > > Cc: Brian King > Signed-off-by: Thomas Falcon > --- > v2: Included statistics that were previously in a separate patch Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v3 3/4] ibmveth: Add GRO support
From: Thomas Falcon Date: Wed, 29 Apr 2015 16:25:46 -0500 > Cc: Brian King > Signed-off-by: Thomas Falcon Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v3 4/4] ibmveth: Add support for Large Receive Offload
From: Thomas Falcon Date: Wed, 29 Apr 2015 16:25:47 -0500 > Enables receiving large packets from other LPARs. These packets > have a -1 IP header checksum, so we must recalculate to have > a valid checksum. > > Signed-off-by: Brian King > Signed-off-by: Thomas Falcon > --- > v3: > -Removed code setting network and transport headers > -get IP header from skb data > Thanks again to Eric Dumazet > > v2: > -Included statistics that were previously in a separate patch > -Zeroed the IP header checksum before calling ip_fast_csum > Thanks to Eric Dumazet. Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] net: fs_enet: Remove non NAPI RX and add NAPI for TX
From: Christophe Leroy Date: Tue, 7 Oct 2014 15:04:53 +0200 (CEST) > When using a MPC8xx as a router, 'perf' shows a significant time spent in > fs_enet_interrupt() and fs_enet_start_xmit(). > 'perf annotate' shows that the time spent in fs_enet_start_xmit is indeed > spent > between spin_unlock_irqrestore() and the following instruction, hence in > interrupt handling. This is due to the TX complete interrupt that fires after > each transmitted packet. > This patchset first remove all non NAPI handling as NAPI has become the only > mode for RX, then adds NAPI for handling TX complete. > This improves NAT TCP throughput by 21% on MPC885 with FEC. > > Tested on MPC885 with FEC. > > [PATCH 1/2] net: fs_enet: Remove non NAPI RX > [PATCH 2/2] net: fs_enet: Add NAPI TX > > Signed-off-by: Christophe Leroy Series applied, thanks. Any particular reason you didn't just put the TX reclaim calls into the existing NAPI handler? That's what other drivers do, because TX reclaim can make SKBs available for RX packet receive on the local cpu. So generally you have one NAPI context that first does any pending TX reclaim, then polls the RX ring for new packets. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: error: 'SCCE_ENET_TXF' undeclared
From: Christophe Leroy Date: Thu, 9 Oct 2014 16:54:43 +0200 (CEST) > [linux-devel:devel-hourly-2014100909 3763/3915] > drivers/net/ethernet/freescale/fs_enet/mac-scc.c:119:32: error: > 'SCCE_ENET_TXF' undeclared > > Due to patch d43a396 net: fs_enet: Add NAPI TX, it appears that some target > compilations are broken. > This is due to the fact that unlike the FEC, the SCC and FCC don't have a TXF > event (complete Frame transmitted) but only TXB (buffer transmitted). > > Signed-off-by: Christophe Leroy Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 25/27] Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq
From: Yijing Wang Date: Wed, 15 Oct 2014 11:07:13 +0800 > Use MSI chip framework instead of arch MSI functions to configure > MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework. > > Signed-off-by: Yijing Wang Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: set back promiscuity mode after restart
From: Christophe Leroy Date: Wed, 22 Oct 2014 09:05:47 +0200 (CEST) > After interface restart (eg: after link disconnection/reconnection), the > bridge > function doesn't work anymore. This is due to the promiscuous mode being > cleared > by the restart. > > The mac-fcc already includes code to set the promiscuous mode back during the > restart. > This patch adds the same handling to mac-fec and mac-scc. > > Tested with bridge function on MPC885 with FEC. > > Reported-by: Germain Montoies > Signed-off-by: Christophe Leroy Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
Hey guys, was looking over the generic GUP while working on a sparc64 issue and I noticed that you guys do speculative page gets, and after talking with Johannes Weiner (CC:'d) about this we don't see how it could be necessary. If interrupts are disabled during the page table scan (which they are), no IPI tlb flushes can arrive. Therefore any removal from the page tables is guarded by interrupts being re-enabled. And as a result, page counts of pages we see in the page tables must always have a count > 0. x86 does direct atomic_add() on &page->_count because of this invariant and I would rather see the generic version do this too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] mm: Update generic gup implementation to handle hugepage directory
From: Benjamin Herrenschmidt Date: Fri, 24 Oct 2014 10:40:35 +1100 > Another option would be to make the generic code use something defined > by the arch to decide whether to use speculative get or > not. I like the idea of keeping the bulk of that code generic... Me too. We could have inlines that do either speculative or non-speculative gets on the pages in some header file and hide the ifdefs in there. ___ 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 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 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" 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 V4 1/2] mm: Update generic gup implementation to handle hugepage directory
From: "Aneesh Kumar K.V" 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 > --- > 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
Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Denis Kirjanov Date: Thu, 30 Oct 2014 09:12:15 +0300 > 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 > > CC: Alexei Starovoitov > CC: Michael Ellerman > Cc: Matt Evans > Signed-off-by: Denis Kirjanov > > v2: Added test rusults So, can I apply this now? ___ 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: Alexei Starovoitov Date: Mon, 3 Nov 2014 09:21:03 -0800 > On Mon, Nov 3, 2014 at 9:06 AM, David Miller wrote: >> From: Denis Kirjanov >> Date: Thu, 30 Oct 2014 09:12:15 +0300 >> >>> 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 >>> >>> CC: Alexei Starovoitov >>> CC: Michael Ellerman >>> Cc: Matt Evans >>> Signed-off-by: Denis Kirjanov >>> >>> v2: Added test rusults >> >> So, can I apply this now? > > I think this question is more towards ppc folks, > since both Daniel and myself said before that it looks ok. > Philippe just tested the previous version of this patch on ppc64le... > I'm guessing that Matt (original author of bpf jit for ppc) is not replying, > because he has no objections. > Either way the addition is tiny and contained, so can go in now. Ok, I have applied this to net-next, thanks everyone. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Denis Kirjanov Date: Thu, 6 Nov 2014 09:02:35 +0300 > Add BPF extension SKF_AD_HATYPE to ppc JIT to check > the hw type of the interface > > JIT off: > [ 69.106783] test_bpf: #20 LD_HATYPE 48 48 PASS > JIT on: > [ 64.721757] test_bpf: #20 LD_HATYPE 7 6 PASS > > CC: Alexei Starovoitov > CC: Daniel Borkmann > CC: Philippe Bergheaud > Signed-off-by: Denis Kirjanov Can I get some reviews please? Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 net-next] PPC: bpf_jit_comp: add SKF_AD_HATYPE instruction
From: Denis Kirjanov Date: Mon, 10 Nov 2014 08:59:43 +0300 > Add BPF extension SKF_AD_HATYPE to ppc JIT to check > the hw type of the interface > > Before: > [ 57.723666] test_bpf: #20 LD_HATYPE > [ 57.723675] BPF filter opcode 0020 (@0) unsupported > [ 57.724168] 48 48 PASS > > After: > [ 103.053184] test_bpf: #20 LD_HATYPE 7 6 PASS > > CC: Alexei Starovoitov > CC: Daniel Borkmann > CC: Philippe Bergheaud > Signed-off-by: Denis Kirjanov > > v2: address Alexei's comments Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] PPC: bpf_jit_comp: Unify BPF_MOD | BPF_X and BPF_DIV | BPF_X
From: Alexei Starovoitov Date: Tue, 18 Nov 2014 07:37:21 -0800 > On Mon, Nov 17, 2014 at 10:58 PM, Denis Kirjanov > wrote: >> Hi Michael, >> >> This patch added no new functionality so I haven't put the test >> results (of course I ran the test suite to check the patch). >> >> The output : >> [ 650.198958] test_bpf: Summary: 60 PASSED, 0 FAILED > > Acked-by: Alexei Starovoitov Applied, thanks everyone. > btw, please don't top post. Seriously, it's my biggest pet peeve. It's like going to a dinner party and eating with your feet. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] af_unix: fix a fatal race with bit fields
From: Benjamin Herrenschmidt Date: Wed, 01 May 2013 11:39:53 +1000 > I'm not even completely certain bytes are safe to be honest, though > probably more than bitfields. I'll poke our compiler people. Older Alpha only has 32-bit and 64-bit loads and stores, so byte sized accesses are not atomic, and therefore use racey read-modify-write sequences. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 net-next] af_unix: fix a fatal race with bit fields
From: Eric Dumazet Date: Wed, 01 May 2013 08:24:03 -0700 > [PATCH v2] af_unix: fix a fatal race with bit fields > > Using bit fields is dangerous on ppc64/sparc64, as the compiler [1] > uses 64bit instructions to manipulate them. > If the 64bit word includes any atomic_t or spinlock_t, we can lose > critical concurrent changes. > > This is happening in af_unix, where unix_sk(sk)->gc_candidate/ > gc_maybe_cycle/lock share the same 64bit word. > > This leads to fatal deadlock, as one/several cpus spin forever > on a spinlock that will never be available again. > > A safer way would be to use a long to store flags. > This way we are sure compiler/arch wont do bad things. > > As we own unix_gc_lock spinlock when clearing or setting bits, > we can use the non atomic __set_bit()/__clear_bit(). > > recursion_level can share the same 64bit location with the spinlock, > as it is set only with this spinlock held. > > [1] bug fixed in gcc-4.8.0 : > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52080 > > Reported-by: Ambrose Feinstein > Signed-off-by: Eric Dumazet Applied and queued up for -stable, thanks Eric. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] net/eth/ibmveth: Fixup retrieval of MAC address
From: Benjamin Herrenschmidt Date: Sat, 04 May 2013 13:19:01 +1000 > Some ancient pHyp versions used to create a 8 bytes local-mac-address > property in the device-tree instead of a 6 bytes one for veth. > > The Linux driver code to deal with that is an insane hack which also > happens to break with some choices of MAC addresses in qemu by testing > for a bit in the address rather than just looking at the size of the > property. > > Sanitize this by doing the latter instead. > > Signed-off-by: Benjamin Herrenschmidt > CC: Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] sparc/PCI: Use PCI_UNKNOWN for unknown power state
From: Bjorn Helgaas Date: Mon, 20 May 2013 17:19:16 -0600 > Previously we initialized dev->current_state to 4 (PCI_D3cold), but I think > we wanted PCI_UNKNOWN (5) here based on the comment and the fact that the > generic version of this code, pci_setup_device(), uses PCI_UNKNOWN. > > Signed-off-by: Bjorn Helgaas Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
From: Sebastian Hesselbarth Date: Wed, 22 May 2013 22:04:01 +0200 > + memcpy((void *)p->value, reg, 6); This cast is completely unnecessary, non-void to void pointer casts are automatic. If it is necessary, because p->value is const, then you are trying to change something behind the OF layer's back and need to use the appropriate interface to change the property contents. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
From: Sebastian Hesselbarth Date: Sun, 26 May 2013 22:06:58 +0200 > good you mention it. I added Grant on Cc and will give a short > sum-up why I casted the const from property->value away here. > > Maybe I overlooked the API for modifying the DT property but as > far as I've seen - there is no API for modifying it. And yes, > you are right, it is kind of an abuse of DT here. Sparc has an of_set_property(), it needs to become generic. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
From: Benjamin Herrenschmidt Date: Mon, 27 May 2013 21:50:04 +1000 > It would be handy to be able to just do something like > > of_set_property(node, name, ptr, len); > > However, that wouldn't help much with the allocation/leak problem, > though at least it would be easier to use. It could also *try* to re-use > the current allocation if the new content is of smaller or equal size. And this is so much better of an interface because it allows the OF implementation to decide how to deal with memory allocation and freeing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
From: Benjamin Herrenschmidt Date: Tue, 28 May 2013 07:50:06 +1000 > On Mon, 2013-05-27 at 14:47 +0200, Arnd Bergmann wrote: >> On Monday 27 May 2013 21:50:04 Benjamin Herrenschmidt wrote: >> > However, that wouldn't help much with the allocation/leak problem, >> > though at least it would be easier to use. It could also *try* to re-use >> > the current allocation if the new content is of smaller or equal size. >> >> I thought that dtc tried to aggressively save space by folding identical >> strings. If you tried to reuse a property that had its contents shared >> with another one, you would get interesting results I guess. > > It used to be only property names, unless that has changed in recent > dtc. But that's a good point, we probably want a flag in struct property > like we have for nodes, indicating whether it comes from the original > fdt data pool or not. This is similar to what the "OF_IS_DYNAMIC()" thing on sparc indicates. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
From: Sebastian Hesselbarth Date: Wed, 29 May 2013 21:32:42 +0200 > For the patches above I suggest to take Patches 1-6 through David > Miller's branch, and Patches 7-12 through Jason Cooper's when the > former have appeared on mainline linux. The patch set has been based > on v3.10-rc3. Patches 1-6 applied to net-next, and patch #1 queued up for -stable. Thanks! ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes
From: Sebastian Hesselbarth Date: Fri, 31 May 2013 08:28:58 +0200 > thanks for pulling these in. I finally found how to check if a patch > already went into -stable. As Jason already said, the mdio patch that > #1 fixes did not yet went into -stable. Can you unqueue it? Sorry for > the confusion. I'll unqueue it, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
From: Eric Dumazet Date: Wed, 05 Jun 2013 21:35:25 -0700 > On Thu, 2013-06-06 at 12:56 +1000, Michael Neuling wrote: >> On Thu, May 23, 2013 at 7:07 AM, Andy Lutomirski wrote: >> > MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API -- >> > it's a hack that steals a bit to indicate to other networking code >> > that a compat entry was used. So don't allow it from a non-compat >> > syscall. >> >> Dave & Linus >> >> This is causing a regression on 64bit powerpc with 32bit usermode. >> When I hit userspace, udev is broken and I suspect all networking is >> broken as well. >> >> Can we please revert 1be374a0518a288147c6a7398792583200a67261 upstream? >> > > It seems to also break x86_64, if using 32bit usermode. Sorry, I only merged this because Ingo Molnar and others kept beating me over the head about merging this fix. Linus please revert, and I will not bow to such pressure in the future, I should know better. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: Unbreak compat_sys_{send,recv}msg
From: Andy Lutomirski
Date: Wed, 5 Jun 2013 22:38:26 -0700
> I broke them in this commit:
>
> commit 1be374a0518a288147c6a7398792583200a67261
> Author: Andy Lutomirski
> Date: Wed May 22 14:07:44 2013 -0700
>
> net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
>
> This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
> MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It
> also reverts some unnecessary checks in sys_socketcall.
>
> Apparently I was suffering from underscore blindness the first time around.
>
> Signed-off-by: Andy Lutomirski
Eric, can you test this patch too?
Thanks.
> ---
>
> I've tested this a little, but I'm not sure I have a great test case.
>
> If the decision is that it's better to leave this for the 3.11, I can send
> a squashed version. Note that the oops that this fixes is only an oops if
> the other patches in the original series are applied.
>
> (FWIW, I wasn't sure how to submit this stuff in the first place. I submitted
> some kernel hardening patches for the x86 tree that converted an access_ok
> oddity in the net code into an actual oops. In a bit of looking, I couldn't
> find any failure mode other than a -EFAULT return without the other patches
> applied. This was clear in the patch series description but not in the
> change log message for the net part.)
>
> include/linux/socket.h | 3 +++
> net/compat.c | 13 +++--
> net/socket.c | 72
> +++---
> 3 files changed, 47 insertions(+), 41 deletions(-)
>
> diff --git a/include/linux/socket.h b/include/linux/socket.h
> index 2b9f74b..e897bdc 100644
> --- a/include/linux/socket.h
> +++ b/include/linux/socket.h
> @@ -321,6 +321,9 @@ extern int put_cmsg(struct msghdr*, int level, int type,
> int len, void *data);
>
> struct timespec;
>
> +/* The __sys_...msg variants allow MSG_CMSG_COMPAT */
> +extern long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags);
> +extern long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags);
> extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int
> vlen,
> unsigned int flags, struct timespec *timeout);
> extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
> diff --git a/net/compat.c b/net/compat.c
> index 79ae884..f0a1ba6 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -734,19 +734,25 @@ static unsigned char nas[21] = {
>
> asmlinkage long compat_sys_sendmsg(int fd, struct compat_msghdr __user *msg,
> unsigned int flags)
> {
> - return sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
> MSG_CMSG_COMPAT);
> + if (flags & MSG_CMSG_COMPAT)
> + return -EINVAL;
> + return __sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
> MSG_CMSG_COMPAT);
> }
>
> asmlinkage long compat_sys_sendmmsg(int fd, struct compat_mmsghdr __user
> *mmsg,
> unsigned int vlen, unsigned int flags)
> {
> + if (flags & MSG_CMSG_COMPAT)
> + return -EINVAL;
> return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
> flags | MSG_CMSG_COMPAT);
> }
>
> asmlinkage long compat_sys_recvmsg(int fd, struct compat_msghdr __user *msg,
> unsigned int flags)
> {
> - return sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
> MSG_CMSG_COMPAT);
> + if (flags & MSG_CMSG_COMPAT)
> + return -EINVAL;
> + return __sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
> MSG_CMSG_COMPAT);
> }
>
> asmlinkage long compat_sys_recv(int fd, void __user *buf, size_t len,
> unsigned int flags)
> @@ -768,6 +774,9 @@ asmlinkage long compat_sys_recvmmsg(int fd, struct
> compat_mmsghdr __user *mmsg,
> int datagrams;
> struct timespec ktspec;
>
> + if (flags & MSG_CMSG_COMPAT)
> + return -EINVAL;
> +
> if (COMPAT_USE_64BIT_TIME)
> return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
> flags | MSG_CMSG_COMPAT,
> diff --git a/net/socket.c b/net/socket.c
> index 0e16888..e216502 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1978,7 +1978,7 @@ struct used_address {
> unsigned int name_len;
> };
>
> -static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
> +static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
>struct msghdr *msg_sys, unsigned int flags,
>struct used_address *used_address)
> {
> @@ -2093,26 +2093,30 @@ out:
> * BSD sendmsg interface
> */
>
> -SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned int,
> flags)
> +long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags)
> {
> int fput_needed, err;
> struct msghdr msg_sys;
> struct socket *sock;
>
> - if (flags & MSG_
Re: [PATCH] net: Unbreak compat_sys_{send,recv}msg
From: Eric Dumazet Date: Thu, 06 Jun 2013 06:45:37 -0700 > On Thu, 2013-06-06 at 00:26 -0700, David Miller wrote: >> From: Andy Lutomirski >> Date: Wed, 5 Jun 2013 22:38:26 -0700 >> >> > I broke them in this commit: >> > >> > commit 1be374a0518a288147c6a7398792583200a67261 >> > Author: Andy Lutomirski >> > Date: Wed May 22 14:07:44 2013 -0700 >> > >> > net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg >> > >> > This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that >> > accept >> > MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It >> > also reverts some unnecessary checks in sys_socketcall. >> > >> > Apparently I was suffering from underscore blindness the first time around. >> > >> > Signed-off-by: Andy Lutomirski >> >> Eric, can you test this patch too? > > Yes, this fixes the problem as well on x86_64 > > Tested-by: Eric Dumazet Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] of: Fix locking vs. interrupts
From: Grant Likely Date: Wed, 12 Jun 2013 10:06:12 +0100 > On Wed, 12 Jun 2013 10:25:56 +0200 (CEST), Thomas Gleixner > wrote: >> On Wed, 12 Jun 2013, Benjamin Herrenschmidt wrote: >> >> > The OF code uses irqsafe locks everywhere except in a handful of functions >> > for no obvious reasons. Since the conversion from the old rwlocks, this >> > now triggers lockdep warnings when used at interrupt time. At least one >> > driver (ibmvscsi) seems to be doing that from softirq context. >> > >> > This converts the few non-irqsafe locks into irqsafe ones, making them >> > consistent with the rest of the code. >> >> Fun. https://lkml.org/lkml/2013/2/4/416 seems to have got lost >> >> > Signed-off-by: Benjamin Herrenschmidt >> > CC: [v3.9+] >> >> Acked-by: Thomas Gleixner >> >> > --- >> > >> > Note: It's silly to access the device-tree at interrupt time in most cases, >> > and we should probably fix ibmvscsi, but for the time being, let's fix the >> >> Right. >> >> > obvious bug. Thomas, this can probably still go into 3.10... If not, I've >> > CCed stable. >> >> Should go through Grant I think. > > Applied, thanks. FWIW: Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/9] PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.
From: Rusty Russell Date: Sun, 16 Jun 2013 14:12:41 +0930 > Sweep of the simple cases. > > Cc: net...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: Julia Lawall > Signed-off-by: Rusty Russell Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 0/3] networking: Use ETH_ALEN where appropriate
From: Joe Perches Date: Thu, 1 Aug 2013 16:17:46 -0700 > Convert the uses mac addresses to ETH_ALEN so > it's easier to find and verify where mac addresses > need to be __aligned(2) Series applied to net-next, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] net: fs_enet: Disable NETIF_F_SG feature for Freescale MPC5121
From: Alexander Popov Date: Wed, 10 Jun 2015 02:57:42 +0300 > skb_copy_from_linear_data() which doesn't work well for non-linear sk_buff: The correct fix is to use an SKB copy routine which can handle non-linear data. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net/ps3_gelic: Fix build error with DEBUG
From: Geoff Levand Date: Wed, 10 Jun 2015 10:19:48 -0700 > When the DEBUG preprocessor macro is defined the ps3_gelic_net driver build > fails due to an undeclared routine gelic_descr_get_status(). This problem > was introduced during the code cleanup of commit > 6b0c21cede22be1f68f0a632c0ca38008ce1abe7 (net: Fix p3_gelic_net sparse > warnings), > which re-arranged the ordering of some of the gelic routines. > > This change just moves the gelic_descr_get_status() routine up in the > ps3_gelic_net.c source file. There is no functional change. > > Fixes build errors like these: > > drivers/net/ethernet/toshiba/ps3_gelic_net.c: error: implicit declaration > of function gelic_descr_get_status > > Signed-off-by: Geoff Levand Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1 linux-next] net: fs_enet: use swap() in fs_enet_rx_napi()
From: Fabian Frederick Date: Wed, 10 Jun 2015 18:33:19 +0200 > Use kernel.h macro definition. > > Thanks to Julia Lawall for Coccinelle scripting support. > > Signed-off-by: Fabian Frederick Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/1] net: fs_enet: Fix NETIF_F_SG feature for Freescale MPC5121
From: Alexander Popov
Date: Sun, 21 Jun 2015 01:32:46 +0300
> Commit 4fc9b87bae25 ("net: fs_enet: Implement NETIF_F_SG feature")
> brings a trouble to Freescale MPC512x: a kernel oops happens
> during sending non-linear sk_buff with .data not aligned by 4.
>
> Log quotation:
...
> The reason:
>
> MPC5121 FEC requires 4-byte alignment for TX data buffer and calls
> tx_skb_align_workaround() for copying sk_buff with not aligned .data to a new
> sk_buff with aligned one. But tx_skb_align_workaround() uses
> skb_copy_from_linear_data() which doesn't work for non-linear sk_buff:
> a new sk_buff has non-zero nr_frags and zero .data_len.
>
> So improve the condition of calling tx_skb_align_workaround() and use
> skb_linearize() in it.
>
> Signed-off-by: Alexander Popov
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] ibmveth: add support for TSO6
From: Thomas Falcon Date: Tue, 14 Jul 2015 10:51:51 -0500 > This patch adds support for a new method of signalling the firmware > that TSO packets are being sent. The new method removes the need to > alter the ip and tcp checksums and allows TSO6 support. > > Signed-off-by: Thomas Falcon Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] openvswitch: allocate nr_node_ids flow_stats instead of num_possible_nodes
From: Chris J Arges Date: Tue, 21 Jul 2015 12:36:33 -0500 > Some architectures like POWER can have a NUMA node_possible_map that > contains sparse entries. This causes memory corruption with openvswitch > since it allocates flow_cache with a multiple of num_possible_nodes() and > assumes the node variable returned by for_each_node will index into > flow->stats[node]. > > Use nr_node_ids to allocate a maximal sparse array instead of > num_possible_nodes(). > > The crash was noticed after 3af229f2 was applied as it changed the > node_possible_map to match node_online_map on boot. > Fixes: 3af229f2071f5b5cb31664be6109561fbe19c861 > > Signed-off-by: Chris J Arges Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 03/10] dpaa_eth: add configurable bpool thresholds
From: Madalin-Cristian Bucur Date: Fri, 24 Jul 2015 15:49:39 + >> -Original Message- >> From: Joe Perches [mailto:j...@perches.com] >> On Wed, 2015-07-22 at 19:16 +0300, Madalin Bucur wrote: >> > Allow the user to tweak the refill threshold and the total number >> > of buffers in the buffer pool. The provided values are for one CPU. >> >> Any value in making these module parameters instead? > > I expect one would (hardly ever) change these to improve some corner > cases then use them with the new values. It may help in the tuning process > but afterwards the bloat to the bootcmd would probably be a nuisance. I think these should be controlled by the existing ethtool infrastructure. Neither the Kconfig mechanism nor module parameters are appropriate, at all. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4, 0/9] Freescale DPAA FMan
From: Date: Wed, 5 Aug 2015 12:25:16 +0300 > The Freescale Data Path Acceleration Architecture (DPAA) > is a set of hardware components on specific QorIQ multicore processors. > This architecture provides the infrastructure to support simplified > sharing of networking interfaces and accelerators by multiple CPU cores > and the accelerators. I think the directory and code structure of this new driver is quite excessive. Because you've split things up _so_ much, you have to have all of these directories, and even worse and much more important to me you have to export so many functions from one source file to another. I think this is way too much. For example, in one file you have a bunch of initialization routines. init_a(), init_b(), init_c(), and you export them all. Then they are always called in sequence: init_a(); init_b(); init_c(); This is completely pointless. You just needed to export one function which calls all three functions. The namespace pollution of this driver is out of control. You really need to completely rework the architecture and layout of this driver before I will even begin to review it again. And the lack of review interest by other developers should be an indication to you how undesirable this code submission is to read. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2 8/9] dpaa_eth: add debugfs entries
From: Madalin Bucur Date: Wed, 5 Aug 2015 18:41:28 +0300 > Export per CPU counters through debugfs. > > Signed-off-by: Madalin Bucur This is absolutely inappropriate. You can export these just fine via ethtool statistics. There is zero reason to add ugly debugfs crap for something like this. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: explicitly remove I flag on TX partial frames
From: Christophe Leroy Date: Tue, 11 Aug 2015 12:11:00 +0200 (CEST) > We are not interested in interrupts for partially transmitted frames, > we have to clear BD_ENET_TX_INTR explicitly otherwise it may remain > from a previously used descriptor. > > Signed-off-by: Christophe Leroy Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: mask interrupts for TX partial frames.
From: Christophe Leroy Date: Tue, 11 Aug 2015 12:11:03 +0200 (CEST) > We are not interested in interrupts for partially transmitted frames. > Unlike SCC and FCC, the FEC doesn't handle the I bit in buffer > descriptors, instead it defines two interrupt bits, TXB and TXF. > > We have to mask TXB in order to only get interrupts once the > frame is fully transmitted. > > Signed-off-by: Christophe Leroy Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 29/31] parisc: handle page-less SG entries
From: James Bottomley Date: Thu, 13 Aug 2015 20:59:20 -0700 > On Thu, 2015-08-13 at 20:30 -0700, Dan Williams wrote: >> On Thu, Aug 13, 2015 at 7:31 AM, Christoph Hellwig wrote: >> > On Wed, Aug 12, 2015 at 09:01:02AM -0700, Linus Torvalds wrote: >> >> I'm assuming that anybody who wants to use the page-less >> >> scatter-gather lists always does so on memory that isn't actually >> >> virtually mapped at all, or only does so on sane architectures that >> >> are cache coherent at a physical level, but I'd like that assumption >> >> *documented* somewhere. >> > >> > It's temporarily mapped by kmap-like helpers. That code isn't in >> > this series. The most recent version of it is here: >> > >> > https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git/commit/?h=pfn&id=de8237c99fdb4352be2193f3a7610e902b9bb2f0 >> > >> > note that it's not doing the cache flushing it would have to do yet, but >> > it's also only enabled for x86 at the moment. >> >> For virtually tagged caches I assume we would temporarily map with >> kmap_atomic_pfn_t(), similar to how drm_clflush_pages() implements >> powerpc support. However with DAX we could end up with multiple >> virtual aliases for a page-less pfn. > > At least on some PA architectures, you have to be very careful. > Improperly managed, multiple aliases will cause the system to crash > (actually a machine check in the cache chequerboard). For the most > temperamental systems, we need the cache line flushed and the alias > mapping ejected from the TLB cache before we access the same page at an > inequivalent alias. Also, I want to mention that on sparc64 we manage the cache aliasing state in the page struct. Until a page is mapped into userspace, we just record the most recent cpu to store into that page with kernel side mappings. Once the page ends up being mapped or the cpu doing kernel side stores changes, we actually perform the cache flush. Generally speaking, I think that all actual physical memory the kernel operates on should have a struct page backing it. So this whole discussion of operating on physical memory in scatter lists without backing page structs feels really foreign to me. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Revert "cxgb3: Check and handle the dma mapping errors"
From: Divy Le ray Date: Wed, 14 Aug 2013 08:57:24 -0700 > On 08/14/2013 02:19 AM, Alexey Kardashevskiy wrote: >> This reverts commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9. >> >> As the tests PPC64 (powernv platform) show, IOMMU pages are leaking >> when transferring big amount of small packets (<=64 bytes), >> "ping -f" and waiting for 15 seconds is the simplest way to confirm >> the bug. >> >> Cc: Linus Torvalds >> Cc: Santosh Rastapur >> Cc: Jay Fenlason >> Cc: David S. Miller >> Cc: Divy Le ray >> Signed-off-by: Alexey Kardashevskiy > > Acked-by: Divy Le Ray Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/7] net: use platform_{get,set}_drvdata()
From: Libo Chen
Date: Thu, 15 Aug 2013 21:01:17 +0800
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
>
> changelog v3:
> remove modify about dev_set_drvdata()
> changelog v2:
> this version add modify record about dev_set_drvdata().
Series applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 0/7] net: use platform_{get,set}_drvdata()
From: David Miller
Date: Thu, 15 Aug 2013 15:23:59 -0700 (PDT)
> From: Libo Chen
> Date: Thu, 15 Aug 2013 21:01:17 +0800
>
>> Use the wrapper functions for getting and setting the driver data using
>> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
>> so we can directly pass a struct platform_device.
>>
>> changelog v3:
>> remove modify about dev_set_drvdata()
>> changelog v2:
>> this version add modify record about dev_set_drvdata().
>
> Series applied.
Actually, I had to revert, these patches break the build.
drivers/net/ethernet/sun/sunhme.c: In function ‘happy_meal_pci_probe’:
drivers/net/ethernet/sun/sunhme.c:3114:2: error: implicit declaration of
function ‘platform_set_drvdata’ [-Werror=implicit-function-declaration]
drivers/net/ethernet/sun/sunhme.c: In function ‘happy_meal_pci_remove’:
drivers/net/ethernet/sun/sunhme.c:3162:9: error: implicit declaration of
function ‘platform_get_drvdata’ [-Werror=implicit-function-declaration]
drivers/net/ethernet/sun/sunhme.c:3162:26: warning: initialization makes
pointer from integer without a cast [enabled by default]
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 0/7] net: use platform_{get,set}_drvdata()
From: Libo Chen
Date: Mon, 19 Aug 2013 19:58:17 +0800
>
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
>
> changelog v4:
> remove modify about happy_meal_pci_probe && happy_meal_pci_remove
> changelog v3:
> remove modify about dev_set_drvdata()
> changelog v2:
> this version add modify record about dev_set_drvdata().
Series applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/8] net: remove unnecessary dev_set_drvdata()
From: Libo Chen Date: Wed, 21 Aug 2013 15:05:37 +0800 > Unnecessary dev_set_drvdata() is removed, because the driver core > clears the driver data to NULL after device_release or on probe failure. Series applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] fs: use inode_set_user to set uid/gid of inode
From: Rui Xiang Date: Fri, 23 Aug 2013 10:48:38 +0800 > Use the new interface to set i_uid/i_gid in inode struct. > > Signed-off-by: Rui Xiang For the networking bits: Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file
From: Aida Mynzhasova Date: Wed, 25 Sep 2013 11:24:23 +0400 > Currently IEEE 1588 timer reference clock source is determined through > hard-coded value in gianfar_ptp driver. This patch allows to select ptp > clock source by means of device tree file node. > > For instance: > > fsl,cksel = <0>; > > for using external (TSEC_TMR_CLK input) high precision timer > reference clock. > > Other acceptable values: > > <1> : eTSEC system clock > <2> : eTSEC1 transmit clock > <3> : RTC clock input > > When this attribute isn't used, eTSEC system clock will serve as > IEEE 1588 timer reference clock. > > Signed-off-by: Aida Mynzhasova Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] net:drivers/net: Miscellaneous conversions to ETH_ALEN
From: Joe Perches Date: Tue, 01 Oct 2013 19:04:40 -0700 > Convert the memset/memcpy uses of 6 to ETH_ALEN > where appropriate. > > Also convert some struct definitions and u8 array > declarations of [6] to ETH_ALEN. > > Signed-off-by: Joe Perches Looks fine, applied, thanks Joe. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 net-next] fix unsafe set_memory_rw from softirq
From: Eric Dumazet Date: Sun, 06 Oct 2013 09:56:32 -0700 > On Fri, 2013-10-04 at 00:14 -0700, Alexei Starovoitov wrote: >> on x86 system with net.core.bpf_jit_enable = 1 > >> cannot reuse jited filter memory, since it's readonly, >> so use original bpf insns memory to hold work_struct >> >> defer kfree of sk_filter until jit completed freeing >> >> tested on x86_64 and i386 >> >> Signed-off-by: Alexei Starovoitov > > Acked-by: Eric Dumazet I've decided to apply this to 'net', thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] gianfar: Enable eTSEC-A002 erratum w/a for all parts
From: Claudiu Manoil Date: Wed, 9 Oct 2013 20:20:40 +0300 > A002 is still in "no plans to fix" state, and applies to all > the current P1/P2 parts as well, so it's resonable to enable > its workaround by default, for all the soc's with etsec. > The impact of not enabling this workaround for affected parts > is that under certain conditons (runt frames or even frames > with RX error detected at PHY level) during controller reset, > the controller might fail to indicate Rx reset (GRS) completion. > > Signed-off-by: Claudiu Manoil Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] gianfar: Enable eTSEC-20 erratum w/a for P2020 Rev1
From: Claudiu Manoil Date: Wed, 9 Oct 2013 20:20:42 +0300 > Enable workaround for P2020/P2010 erratum eTSEC 20, > "Excess delays when transmitting TOE=1 large frames". > The impact is that frames lager than 2500-bytes for which > TOE (i.e. TCP/IP hw accelerations like Tx csum) is enabled > may see excess delay before start of transmission. > This erratum was fixed in Rev 2.0. > > Signed-off-by: Claudiu Manoil Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] gianfar: Use mpc85xx support for errata detection
From: Claudiu Manoil Date: Wed, 9 Oct 2013 20:20:41 +0300 > Use the macros and defines from mpc85xx.h to simplify > and prevent errors in identifying a mpc85xx based SoC > for errata detection. > This should help enabling (and identifying) workarounds > for various mpc85xx based chips and revisions. > For instance, express MPC8548 Rev.2 as: > (SVR_SOC_VER(svr) == SVR_8548) && (SVR_REV(svr) == 0x20) > instead of: > (pvr == 0x80210020 && mod == 0x8030 && rev == 0x0020) > > Signed-off-by: Claudiu Manoil Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: "powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file" was added twice
From: Aida Mynzhasova Date: Sat, 12 Oct 2013 18:54:42 +0400 > Hi, > > recently I looked through commits in kernel/git/torvalds/linux.git and > I noticed that my patch (old and new version) was added twice (by > David S. Miller): > > e58f6f4fb4eada7867014bfaec898f03afbce5c2 > 894116bd0e9b7749a0c4b6c62dec13c2a0ccef68 > > I think this is not good, and only > e58f6f4fb4eada7867014bfaec898f03afbce5c2 should be added. Read the code history properly. First 894116bd0e9b7749a0c4b6c62dec13c2a0ccef68 got applied, as you say accidently. Then I reverted it, see commit 3f3f0960aff951c5df6e42ce292d1593a2520646. Then I applied the correct version which is commit e58f6f4fb4eada7867014bfaec898f03afbce5c2. I didn't respond at all the first time you pointed this out hoping you would figure it out on your own. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese
Date: Sat, 9 Feb 2013 10:49:12 +0100
> Until now, the MPC5200 FEC ethernet driver relied upon the bootloader
> (U-Boot) to write the MAC address into the ethernet controller
> registers. The Linux driver should not rely on such a thing. So
> lets read the MAC address from the DT as it should be done here.
>
> This fixes a problem with a MPC5200 board that uses the SPL U-Boot
> version without FEC initialization before Linux booting for
> boot speedup.
>
> Additionally a status line will now be printed upon successful
> driver probing, also displaying this MAC address.
>
> Signed-off-by: Stefan Roese
I don't think this is a conservative enough change.
You have to keep the MAC register reading code around, as a backup
code path in case the OF device node lacks a MAC address, also:
> + if (!is_zero_ether_addr(mpc52xx_fec_mac_addr)) {
I really wish I would have caught this terrible module parameter
when the driver was initially submitted.
I would just get rid of this, and have a priority list of cases:
1) First, try OF node MAC address, if not present or invalid, then:
2) Read from MAC address registers, if invalid, then:
3) Log a warning message, and choose a random MAC address.
That way no matter what happens, the user will at least have a
functioning networking device.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Bhushan Bharat-R65777 Date: Tue, 12 Feb 2013 10:56:05 + > Why we read from MAC registers if Linux should not rely on bootloader? Because it used to and if you just remove that code then you break existing setups, and I explicitly told him to code things this way. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese Date: Tue, 12 Feb 2013 10:08:08 +0100 > Until now, the MPC5200 FEC ethernet driver relied upon the bootloader > (U-Boot) to write the MAC address into the ethernet controller > registers. The Linux driver should not rely on such a thing. So > lets read the MAC address from the DT as it should be done here. > > The following priority is now used to read the MAC address: > > 1) First, try OF node MAC address, if not present or invalid, then: > > 2) Read from MAC address registers, if invalid, then: > > 3) Log a warning message, and choose a random MAC address. > > This fixes a problem with a MPC5200 board that uses the SPL U-Boot > version without FEC initialization before Linux booting for > boot speedup. > > Additionally a status line is now be printed upon successful > driver probing, also displaying this MAC address. > > Signed-off-by: Stefan Roese Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] net: fec_mpc52xx: Read MAC address from device-tree
From: Stefan Roese Date: Tue, 12 Feb 2013 14:05:38 +0100 > v3: > - Use of_get_mac_address() instead of of_get_property() Just to clarify, I applied this version (v3), not v2 (which I just replied to with "applied"). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net] gianfar: fix compile fail for NET_POLL=y due to struct packing
From: Paul Gortmaker
Date: Sun, 24 Feb 2013 10:38:31 -0500
> Commit ee873fda3bec7c668407b837fc5519eb961fcd37 ("gianfar: Pack struct
> gfar_priv_grp into three cachelines") moved the irq number and names
> off into a separate struct and created accessors for them. However
> it was never tested with NET_POLL enabled, and so some conversions
> that were simply overlooked went undetected until now.
>
> Make the netpoll ones also use the gfar_irq() accessors.
>
> Reported-by: Benjamin Herrenschmidt
> Cc: Benjamin Herrenschmidt
> Cc: Claudiu Manoil
> Cc: Jianhua Xie
> Signed-off-by: Paul Gortmaker
Applied, thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next] drivers:net: Remove unnecessary OOM messages after netdev_alloc_skb
From: Joe Perches Date: Fri, 8 Mar 2013 17:03:25 -0800 > Emitting netdev_alloc_skb and netdev_alloc_skb_ip_align OOM > messages is unnecessary as there is already a dump_stack > after allocation failures. > > Other trivial changes around these removals: > > Convert a few comparisons of pointer to 0 to !pointer. > Change flow to remove unnecessary label. > Remove now unused variable. > Hoist assignment from if. > > Signed-off-by: Joe Perches Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Thu, 14 Mar 2013 19:08:31 +0100 > This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver > instead of rolling its own implementation. As a result, all users of this > mv643xx_eth driver are converted to register an "orion-mdio" platform_device. > The mvmdio driver is also updated to support an interrupt line which reports > SMI error/completion, and to allow traditionnal platform device registration > instead of just device tree. > > David, I think it makes sense for you to merge all of this, since we do > not want the architecture files to be desynchronized from the mv643xx_eth to > avoid runtime breakage. The potential for merge conflicts should be very > small. All applied to net-next, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) > From: Florian Fainelli > Date: Thu, 14 Mar 2013 19:08:31 +0100 > >> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver >> instead of rolling its own implementation. As a result, all users of this >> mv643xx_eth driver are converted to register an "orion-mdio" platform_device. >> The mvmdio driver is also updated to support an interrupt line which reports >> SMI error/completion, and to allow traditionnal platform device registration >> instead of just device tree. >> >> David, I think it makes sense for you to merge all of this, since we do >> not want the architecture files to be desynchronized from the mv643xx_eth to >> avoid runtime breakage. The potential for merge conflicts should be very >> small. > > All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Fri, 15 Mar 2013 13:53:10 +0100 > Le 03/15/13 13:55, David Miller a écrit : >> From: David Miller >> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) >> >>> From: Florian Fainelli >>> Date: Thu, 14 Mar 2013 19:08:31 +0100 >>> >>>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus >>>> driver >>>> instead of rolling its own implementation. As a result, all users of >>>> this >>>> mv643xx_eth driver are converted to register an "orion-mdio" >>>> platform_device. >>>> The mvmdio driver is also updated to support an interrupt line which >>>> reports >>>> SMI error/completion, and to allow traditionnal platform device >>>> registration >>>> instead of just device tree. >>>> >>>> David, I think it makes sense for you to merge all of this, since we >>>> do >>>> not want the architecture files to be desynchronized from the >>>> mv643xx_eth to >>>> avoid runtime breakage. The potential for merge conflicts should be >>>> very small. >>> >>> All applied to net-next, thanks. >> >> Actually, reverted. Please send me code which actually compiles: >> >> drivers/net/ethernet/marvell/mvmdio.c: In function >> ‘orion_mdio_wait_ready’: >> drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ >> undeclared (first use in this function) >> drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared >> identifier is reported only once for each function it appears in >> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: >> drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ >> undeclared (first use in this function) >> make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 >> >> And don't use Kconfig dependencies to work around this, fix it >> properly. > > Is there any platform out there for which we do not have a NO_IRQ > definition by now? If so, what is it? Obviously if x86_64 doesn't even build your changes, that is one such platform. Also, is grep not working on your computer? Platforms are absolutely no required to have this define, zero is the only valid "no IRQ" which is portable in any way. This is an old and tired topic, portable code does not use NO_IRQ, and that's simply the end of it. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Fri, 22 Mar 2013 14:39:24 +0100 > This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver > instead of rolling its own implementation. As a result, all users of this > mv643xx_eth driver are converted to register an "orion-mdio" platform_device. > The mvmdio driver is also updated to support an interrupt line which reports > SMI error/completion, and to allow traditionnal platform device registration > instead of just device tree. > > David, I think it makes sense for you to merge all of this, since we do > not want the architecture files to be desynchronized from the mv643xx_eth to > avoid runtime breakage. The potential for merge conflicts should be very > small. Series applied to net-next, thanks Florian. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] Fix for mv643xx_eth built as module
From: Florian Fainelli Date: Sun, 24 Mar 2013 21:48:33 +0100 > Hello Simon, > > Le dimanche 24 mars 2013 21:33:58, Simon Baatz a écrit : >> Recently [1], mv643xx_eth was changed to make use of mvmdio. However, >> this change introduces two problems when mvmdio and mv643xx_eth are >> built as modules: >> >> - mvmdio is not loaded automatically by udev >> - mv643xx_eth oopses when it can't find its PHY, i.e. when mvmdio is >> not yet loaded >> >> The first problem can be fixed easily by adding a module alias for the >> respective platform device. The proposed fix for the second problem >> uses EPROBE_DEFER as suggested by Thomas Petazzoni when the driver >> can't find its PHY. >> >> These patches apply on top of Florian Fainelli's patchset. They have >> been tested on Marvel Kirkwood non-DT. > > Both fixes look good to me, thanks for fixing this! > > Acked-by: Florian Fainelli All applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth Date: Thu, 11 Apr 2013 17:27:03 +0200 > On Thu, Apr 11, 2013 at 5:03 PM, Willy Tarreau wrote: >> On Thu, Apr 11, 2013 at 04:47:49PM +0200, Sebastian Hesselbarth wrote: >>> I tried todays net-next on top of 3.9-rc6 without any gro patch, with >>> the initial >>> patch (Soeren) and your proposed patch (Willy). The results show that >>> both patches >>> allow a significant increase in throughput compared to >>> netif_receive_skb (!gro, !lro) >>> alone. Having gro with lro disabled gives some 2% more throughput >>> compared to lro only. >> >> Indeed this is consistent with my memories, since Eric improved the >> GRO path, it became faster than LRO on this chip. > > I don't have a strong opinion on whether Soeren's or your proposal should > be submitted. But I insist on having one of them in, as GRO significantly > improves the common use case, is enabled by default, and not as > constrained as LRO. I think, as per other drivers, LRO should be eliminated completely from all drivers, including this one, and GRO used exclusively instead. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
From: Sebastian Hesselbarth Date: Thu, 11 Apr 2013 11:29:32 +0200 > With introduction of common clock framework and the ability to provide > gated clocks, mv643xx_eth required calls to get and enable these clock > gates on some platforms. Back then, common clock framework api wasn't > safe for architectures without support for common clocks. This has > changed now and there are also managed (devm_) counterparts for clock > related functions. > > The second patch in this series, also converts kzalloc to devm_kzalloc > where applicable. > > Both patches have been sent to the corresponding mailing lists as > individual patches before. To get the order required to apply them right, > this patch set combines both patches into one set. Both applied to net-next, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: mv643xx_eth: Add GRO support
From: Sebastian Hesselbarth Date: Thu, 11 Apr 2013 14:40:23 +0200 > This patch adds GRO support to mv643xx_eth by making it invoke > napi_gro_receive instead of netif_receive_skb. > > Signed-off-by: Soeren Moch > Signed-off-by: Sebastian Hesselbarth Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] net: mv643xx_eth: remove deprecated inet_lro support
From: Eric Dumazet Date: Fri, 12 Apr 2013 05:55:39 -0700 > On Fri, 2013-04-12 at 11:20 +0200, Sebastian Hesselbarth wrote: >> With recent support for GRO, there is no need to keep both LRO and >> GRO. This patch therefore removes the deprecated inet_lro support >> from mv643xx_eth. This is work is based on an experimental patch >> provided by Eric Dumazet and Willy Tarreau. >> >> Signed-off-by: Sebastian Hesselbarth >> Based-on-patch-by: Eric Dumazet >> Based-on-patch-by: Willy Tarreau >> --- >> Changes from v1: >> - also remove INET_LRO from Kconfig (Reported by Eric Dumazet) > > Thanks for finishing this patch > > Signed-off-by: Eric Dumazet Applied, but this driver is full of skeletons: drivers/net/ethernet/marvell/mv643xx_eth.c: In function ‘rxq_refill’: drivers/net/ethernet/marvell/mv643xx_eth.c:618:19: error: invalid operands to binary - (have ‘sk_buff_data_t’ and ‘unsigned char *’) which is: size = skb->end - skb->data; that is absolutely not a legal computation. It happens to be in the only configuration for which this driver can be enabled in Kconfig but that is no excuse for it :-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] freescale: Update logging style
From: Joe Perches Date: Sat, 13 Apr 2013 22:03:16 -0700 > Convert various printk logging styles to current styles. > > Uncompiled, untested. > > Joe Perches (3): > fec: Convert printks to netdev_ > gianfar: Use netdev_ when possible > ucc_geth: Convert ugeth_ to pr_ All applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 07/13] sparc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang Date: Fri, 25 Apr 2014 17:18:29 +0800 > Now we can use new pci_is_bridge() helper function > to simplify code. > > Signed-off-by: Yijing Wang Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [resend] net: get rid of SET_ETHTOOL_OPS
From: Wilfried Klaebe Date: Sun, 11 May 2014 00:12:32 + > net: get rid of SET_ETHTOOL_OPS > > Dave Miller mentioned he'd like to see SET_ETHTOOL_OPS gone. > This does that. > > Mostly done via coccinelle script: > @@ > struct ethtool_ops *ops; > struct net_device *dev; > @@ > - SET_ETHTOOL_OPS(dev, ops); > + dev->ethtool_ops = ops; > > Compile tested only, but I'd seriously wonder if this broke anything. > > Suggested-by: Dave Miller > Signed-off-by: Wilfried Klaebe Applied to net-next, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH RESEND 0/9 net-next] net: of_phy_connect_fixed_link removal
Please address Sergei's feedback, except the indentation one which as you stated is correct. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH net-next v2 0/9] net: of_phy_connect_fixed_link removal
From: Florian Fainelli Date: Thu, 22 May 2014 09:47:42 -0700 > This patch set removes of_phy_connect_fixed_link() from the tree now that > we have a better solution for dealing with fixed PHY (emulated PHY) devices > for drivers that require them. > > First two patches update the 'fixed-link' Device Tree binding and drivers to > refere to it. > > Patches 3 to 7 update the in-tree network drivers that use > of_phy_connect_fixed_link() > > Patch 8 removes of_phy_connect_fixed_link > > Patch 9 removes the PowerPC code that parsed the 'fixed-link' property. > > Patch 9 can be merged via the net-next tree if the PowerPC folks ack it, > but it really has to be merged after the first 8 patches in order to avoid > breakage. Series applied, if someone doesn't like patch #9 we can fix it up with a followup patch or revert. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/8xx: Remove empty asm/mpc8xx.h
From: Scott Wood Date: Fri, 20 Jun 2014 20:02:07 -0500 > m8xx_pcmcia_ops was the only thing in this file (other than a comment > that describes a usage that doesn't match the file's contents); now > that m8xx_pcmcia_ops is gone, remove the empty file. > > Signed-off-by: Scott Wood For networking bits: Acked-by: David S. Miller ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc: bpf: Use correct mask while accessing the VLAN tag
From: Denis Kirjanov Date: Wed, 25 Jun 2014 21:34:56 +0400 > To get a full tag (and not just a VID) we should access the TCI > except the VLAN_TAG_PRESENT field (which means that 802.1q header > is present). Also ensure that the VLAN_TAG_PRESENT stay on its place > > Signed-off-by: Denis Kirjanov Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc: bpf: Fix the broken LD_VLAN_TAG_PRESENT test
From: Denis Kirjanov Date: Wed, 25 Jun 2014 21:34:57 +0400 > We have to return the boolean here if the tag presents > or not, not just ANDing the TCI with the mask which results to: > > [ 709.412097] test_bpf: #18 LD_VLAN_TAG_PRESENT > [ 709.412245] ret 4096 != 1 > [ 709.412332] ret 4096 != 1 > [ 709.412333] FAIL (2 times) > > Signed-off-by: Denis Kirjanov Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/30] drivers/net: remove unnecessary break after return
From: Fabian Frederick Date: Sun, 20 Jul 2014 16:16:08 +0200 > Second patchset after "remove unnecessary break after goto" addressing break > redundancy on drivers/net branch > (suggested by Joe Perches) All applied except the i40e patch, which did not apply to net-next at all. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: fs_enet: fix reference counting for phy_node
From: Uwe Kleine-König
Date: Thu, 7 Aug 2014 23:06:00 +0200
> Make sure that fs_enet_probe is left with a reference to the phy node.
> In the presence of a phy handle this is already the case as
> of_parse_phandle returns a reference. In the fixed phy case a call to
> of_node_get is necessary. Otherwise the error path and remove function
> drop a reference the driver isn't holding.
>
> Fixes: bb74d9a4a87b ("fs_enet: use the new fixed PHY helpers")
> Signed-off-by: Uwe Kleine-König
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] net: ucc_geth: drop acquired references in probe error path and remove
From: Uwe Kleine-König Date: Thu, 7 Aug 2014 23:48:24 +0200 > The ucc_geth_probe function assigns to ug_info->tbi_node and > ug_info->phy_node a value returned by of_parse_phandle which returns a > new reference. Put this reference again in the error path of > ucc_geth_probe and when removing the device. > > Signed-off-by: Uwe Kleine-König Applied. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] net: ucc_geth: make probe consistently acquire a reference to the phy node
From: Uwe Kleine-König
Date: Thu, 7 Aug 2014 23:48:25 +0200
> When the driver attaches to a device that has a phy handle the probe
> routine returns with a reference to that node. This reference is
> correctly dropped in the error path and the remove function. In the
> fixed phy case however no reference is acquired and so the error path
> might drop a reference the driver isn't holding. Fix that by getting a
> reference to the MAC.
>
> Fixes: 87009814cdbb ("ucc_geth: use the new fixed PHY helpers")
> Signed-off-by: Uwe Kleine-König
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] net: ucc_geth: Don't use the MAC as PHY without a fixed link
From: Uwe Kleine-König
Date: Thu, 7 Aug 2014 23:48:26 +0200
> This matches what the other drivers using fixed-link support do and
> restores the behaviour before commit 87009814cdbb ("ucc_geth: use the
> new fixed PHY helpers") for the affected device trees (i.e. no
> phy-handle and no fixed-link).
>
> Fixes: 87009814cdbb ("ucc_geth: use the new fixed PHY helpers")
> Signed-off-by: Uwe Kleine-König
Applied.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
