* [PATCH net-next] openvswitch: allow output of MPLS packets on tunnel vports
From: Simon Horman @ 2016-03-15 2:52 UTC (permalink / raw)
To: Pravin Shelar, David Miller; +Cc: Jesse Gross, netdev, dev, Simon Horman
From: Simon Horman <horms@verge.net.au>
Currently output of MPLS packets on tunnel vports is not allowed by Open
vSwitch. This is because historically encapsulation was done in such a way
that the inner_protocol field of the skb needed to hold the inner protocol
for both MPLS and tunnel encapsulation in order for GSO segmentation to be
performed correctly.
Since b2acd1dc3949 ("openvswitch: Use regular GRE net_device instead of
vport") Open vSwitch makes use of lwt to output to tunnel netdevs which
perform encapsulation. As no drivers expose support for MPLS offloads this
means that GSO packets are segmented in software by validate_xmit_skb(),
which is called from __dev_queue_xmit(), before tunnel encapsulation occurs.
This means that the inner protocol of MPLS is no longer needed by the time
encapsulation occurs and the contention on the inner_protocol field of the
skb no longer occurs.
Thus it is now safe to output MPLS to tunnel vports.
Signed-off-by: Simon Horman <horms@verge.net.au>
---
Lightly tested with Geneve, GRE and VXLAN
---
net/openvswitch/flow_netlink.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 58b8efc23668..689c17264221 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2044,9 +2044,6 @@ static int validate_set(const struct nlattr *a,
break;
case OVS_KEY_ATTR_TUNNEL:
- if (eth_p_mpls(eth_type))
- return -EINVAL;
-
if (masked)
return -EINVAL; /* Masked tunnel set not supported. */
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] openvswitch: allow output of MPLS packets on tunnel vports
From: Simon Horman @ 2016-03-15 3:00 UTC (permalink / raw)
To: Pravin Shelar, David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1458010362-17878-1-git-send-email-simon.horman-wFxRvT7yatFl57MIdRCFDg@public.gmane.org>
On Tue, Mar 15, 2016 at 11:52:42AM +0900, Simon Horman wrote:
> From: Simon Horman <horms@verge.net.au>
Sorry, I mixed up my own email address somehow.
I will repost.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* [PATCH net-next repost] openvswitch: allow output of MPLS packets on tunnel vports
From: Simon Horman @ 2016-03-15 3:00 UTC (permalink / raw)
To: Pravin Shelar, David Miller; +Cc: Jesse Gross, netdev, dev, Simon Horman
Currently output of MPLS packets on tunnel vports is not allowed by Open
vSwitch. This is because historically encapsulation was done in such a way
that the inner_protocol field of the skb needed to hold the inner protocol
for both MPLS and tunnel encapsulation in order for GSO segmentation to be
performed correctly.
Since b2acd1dc3949 ("openvswitch: Use regular GRE net_device instead of
vport") Open vSwitch makes use of lwt to output to tunnel netdevs which
perform encapsulation. As no drivers expose support for MPLS offloads this
means that GSO packets are segmented in software by validate_xmit_skb(),
which is called from __dev_queue_xmit(), before tunnel encapsulation occurs.
This means that the inner protocol of MPLS is no longer needed by the time
encapsulation occurs and the contention on the inner_protocol field of the
skb no longer occurs.
Thus it is now safe to output MPLS to tunnel vports.
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
* Lightly tested with Geneve, GRE and VXLAN
* Reposted with my desired email for this work
---
net/openvswitch/flow_netlink.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
index 58b8efc23668..689c17264221 100644
--- a/net/openvswitch/flow_netlink.c
+++ b/net/openvswitch/flow_netlink.c
@@ -2044,9 +2044,6 @@ static int validate_set(const struct nlattr *a,
break;
case OVS_KEY_ATTR_TUNNEL:
- if (eth_p_mpls(eth_type))
- return -EINVAL;
-
if (masked)
return -EINVAL; /* Masked tunnel set not supported. */
--
2.1.4
^ permalink raw reply related
* Re: [PATCH V4 0/3] basic busy polling support for vhost_net
From: Jason Wang @ 2016-03-15 3:10 UTC (permalink / raw)
To: Michael Rapoport, Greg Kurz
Cc: yang.zhang.wz, kvm, mst, netdev, linux-kernel, virtualization,
borntraeger
In-Reply-To: <201603100648.u2A6mSTl020833@d06av07.portsmouth.uk.ibm.com>
On 03/10/2016 02:48 PM, Michael Rapoport wrote:
> Hi Greg,
>
>> > Greg Kurz <gkurz@linux.vnet.ibm.com> wrote on 03/09/2016 09:26:45 PM:
>>> > > On Fri, 4 Mar 2016 06:24:50 -0500
>>> > > Jason Wang <jasowang@redhat.com> wrote:
>> >
>>> > > This series tries to add basic busy polling for vhost net. The idea is
>>> > > simple: at the end of tx/rx processing, busy polling for new tx added
>>> > > descriptor and rx receive socket for a while. The maximum number of
>>> > > time (in us) could be spent on busy polling was specified ioctl.
>>> > >
>>> > > Test A were done through:
>>> > >
>>> > > - 50 us as busy loop timeout
>>> > > - Netperf 2.6
>>> > > - Two machines with back to back connected mlx4
>> >
>> > Hi Jason,
>> >
>> > Could this also improve performance if both VMs are
>> > on the same host system ?
> I've experimented a little with Jason's patches and guest-to-guest netperf
> when both guests were on the same host, and I saw improvements for that
> case.
>
Good to know this, I haven't tested this before but from the codes, it
should work for VM2VM case too.
Thanks a lot for the testing.
^ permalink raw reply
* Re: [PATCH V2 net 0/4] net: hns: bugs fix about hns driver
From: Yankejian (Hackim Yim) @ 2016-03-15 3:14 UTC (permalink / raw)
To: David Miller, lisheng011
Cc: yisen.zhuang, xieqianqian, huangdaode, salil.mehta,
andriy.shevchenko, netdev, haifeng.wei, charles.chenxin, linuxarm
In-Reply-To: <20160311.115639.981111219744892959.davem@davemloft.net>
On 2016/3/12 0:56, David Miller wrote:
> This does not work.
>
> I will not allow two sets of people sending me patches in parallel to the
> same driver at the same time.
>
> Have one person manage the maintainence of this driver and consolidate the
> patch submissions to me.
>
> Thanks.
>
> .
>
Hi David,
Thanks for your reply. we will upstream the patches one by one. And we will ask Daode Huang to help us
to upsream.
MBR, Kejian
^ permalink raw reply
* RE: [PATCH 1/2] arm64: insn: remove BUG_ON from codegen
From: 平松雅巳 / HIRAMATU，MASAMI @ 2016-03-15 4:28 UTC (permalink / raw)
To: 'Zi Shen Lim', Will Deacon, Alexei Starovoitov,
David S. Miller, Catalin Marinas
Cc: Rabin Vincent, linux-arm-kernel@lists.infradead.org,
netdev@vger.kernel.org, sysp-manager
In-Reply-To: <1452756802-16511-1-git-send-email-zlim.lnx@gmail.com>
>
>During code generation, we used to BUG_ON unknown/unsupported encoding
>or invalid parameters.
>
>Instead, now we report these as errors and simply return the
>instruction AARCH64_BREAK_FAULT. Users of these codegen helpers should
>check for and handle this failure condition as appropriate.
>
>Otherwise, unhandled codegen failure will result in trapping at
>run-time due to AARCH64_BREAK_FAULT, which is arguably better than a
>BUG_ON.
Looks good to me.
Reviewed-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Thanks,
>
>Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
>Cc: Will Deacon <will.deacon@arm.com>
>---
>Per discussion here: http://www.spinics.net/lists/arm-kernel/msg474179.html
>
> arch/arm64/kernel/insn.c | 165 ++++++++++++++++++++++++++++++++---------------
> 1 file changed, 112 insertions(+), 53 deletions(-)
>
>diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
>index c08b9ad..7371455 100644
>--- a/arch/arm64/kernel/insn.c
>+++ b/arch/arm64/kernel/insn.c
>@@ -2,7 +2,7 @@
> * Copyright (C) 2013 Huawei Ltd.
> * Author: Jiang Liu <liuj97@gmail.com>
> *
>- * Copyright (C) 2014 Zi Shen Lim <zlim.lnx@gmail.com>
>+ * Copyright (C) 2014-2016 Zi Shen Lim <zlim.lnx@gmail.com>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License version 2 as
>@@ -363,6 +363,9 @@ u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
> u32 immlo, immhi, mask;
> int shift;
>
>+ if (insn == AARCH64_BREAK_FAULT)
>+ return AARCH64_BREAK_FAULT;
>+
> switch (type) {
> case AARCH64_INSN_IMM_ADR:
> shift = 0;
>@@ -377,7 +380,7 @@ u32 __kprobes aarch64_insn_encode_immediate(enum aarch64_insn_imm_type type,
> if (aarch64_get_imm_shift_mask(type, &mask, &shift) < 0) {
> pr_err("aarch64_insn_encode_immediate: unknown immediate encoding %d\n",
> type);
>- return 0;
>+ return AARCH64_BREAK_FAULT;
> }
> }
>
>@@ -394,9 +397,12 @@ static u32 aarch64_insn_encode_register(enum aarch64_insn_register_type type,
> {
> int shift;
>
>+ if (insn == AARCH64_BREAK_FAULT)
>+ return AARCH64_BREAK_FAULT;
>+
> if (reg < AARCH64_INSN_REG_0 || reg > AARCH64_INSN_REG_SP) {
> pr_err("%s: unknown register encoding %d\n", __func__, reg);
>- return 0;
>+ return AARCH64_BREAK_FAULT;
> }
>
> switch (type) {
>@@ -417,7 +423,7 @@ static u32 aarch64_insn_encode_register(enum aarch64_insn_register_type type,
> default:
> pr_err("%s: unknown register type encoding %d\n", __func__,
> type);
>- return 0;
>+ return AARCH64_BREAK_FAULT;
> }
>
> insn &= ~(GENMASK(4, 0) << shift);
>@@ -446,7 +452,7 @@ static u32 aarch64_insn_encode_ldst_size(enum aarch64_insn_size_type type,
> break;
> default:
> pr_err("%s: unknown size encoding %d\n", __func__, type);
>- return 0;
>+ return AARCH64_BREAK_FAULT;
> }
>
> insn &= ~GENMASK(31, 30);
>@@ -460,14 +466,17 @@ static inline long branch_imm_common(unsigned long pc, unsigned long addr,
> {
> long offset;
>
>- /*
>- * PC: A 64-bit Program Counter holding the address of the current
>- * instruction. A64 instructions must be word-aligned.
>- */
>- BUG_ON((pc & 0x3) || (addr & 0x3));
>+ if ((pc & 0x3) || (addr & 0x3)) {
>+ pr_err("%s: A64 instructions must be word aligned\n", __func__);
>+ return range;
>+ }
>
> offset = ((long)addr - (long)pc);
>- BUG_ON(offset < -range || offset >= range);
>+
>+ if (offset < -range || offset >= range) {
>+ pr_err("%s: offset out of range\n", __func__);
>+ return range;
>+ }
>
> return offset;
> }
>@@ -484,6 +493,8 @@ u32 __kprobes aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
> * texts are within +/-128M.
> */
> offset = branch_imm_common(pc, addr, SZ_128M);
>+ if (offset >= SZ_128M)
>+ return AARCH64_BREAK_FAULT;
>
> switch (type) {
> case AARCH64_INSN_BRANCH_LINK:
>@@ -493,7 +504,7 @@ u32 __kprobes aarch64_insn_gen_branch_imm(unsigned long pc, unsigned long addr,
> insn = aarch64_insn_get_b_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown branch encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -510,6 +521,8 @@ u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr,
> long offset;
>
> offset = branch_imm_common(pc, addr, SZ_1M);
>+ if (offset >= SZ_1M)
>+ return AARCH64_BREAK_FAULT;
>
> switch (type) {
> case AARCH64_INSN_BRANCH_COMP_ZERO:
>@@ -519,7 +532,7 @@ u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr,
> insn = aarch64_insn_get_cbnz_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown branch encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -530,7 +543,7 @@ u32 aarch64_insn_gen_comp_branch_imm(unsigned long pc, unsigned long addr,
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -550,7 +563,10 @@ u32 aarch64_insn_gen_cond_branch_imm(unsigned long pc, unsigned long addr,
>
> insn = aarch64_insn_get_bcond_value();
>
>- BUG_ON(cond < AARCH64_INSN_COND_EQ || cond > AARCH64_INSN_COND_AL);
>+ if (cond < AARCH64_INSN_COND_EQ || cond > AARCH64_INSN_COND_AL) {
>+ pr_err("%s: unknown condition encoding %d\n", __func__, cond);
>+ return AARCH64_BREAK_FAULT;
>+ }
> insn |= cond;
>
> return aarch64_insn_encode_immediate(AARCH64_INSN_IMM_19, insn,
>@@ -583,7 +599,7 @@ u32 aarch64_insn_gen_branch_reg(enum aarch64_insn_register reg,
> insn = aarch64_insn_get_ret_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown branch encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -606,7 +622,7 @@ u32 aarch64_insn_gen_load_store_reg(enum aarch64_insn_register reg,
> insn = aarch64_insn_get_str_reg_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown load/store encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -645,26 +661,30 @@ u32 aarch64_insn_gen_load_store_pair(enum aarch64_insn_register reg1,
> insn = aarch64_insn_get_stp_post_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown load/store encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
> switch (variant) {
> case AARCH64_INSN_VARIANT_32BIT:
>- /* offset must be multiples of 4 in the range [-256, 252] */
>- BUG_ON(offset & 0x3);
>- BUG_ON(offset < -256 || offset > 252);
>+ if ((offset & 0x3) || (offset < -256) || (offset > 252)) {
>+ pr_err("%s: offset must be multiples of 4 in the range of [-256, 252] %d\n",
>+ __func__, offset);
>+ return AARCH64_BREAK_FAULT;
>+ }
> shift = 2;
> break;
> case AARCH64_INSN_VARIANT_64BIT:
>- /* offset must be multiples of 8 in the range [-512, 504] */
>- BUG_ON(offset & 0x7);
>- BUG_ON(offset < -512 || offset > 504);
>+ if ((offset & 0x7) || (offset < -512) || (offset > 504)) {
>+ pr_err("%s: offset must be multiples of 8 in the range of [-512, 504] %d\n",
>+ __func__, offset);
>+ return AARCH64_BREAK_FAULT;
>+ }
> shift = 3;
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -702,7 +722,7 @@ u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_subs_imm_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown add/sub encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -713,11 +733,14 @@ u32 aarch64_insn_gen_add_sub_imm(enum aarch64_insn_register dst,
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>- BUG_ON(imm & ~(SZ_4K - 1));
>+ if (imm & ~(SZ_4K - 1)) {
>+ pr_err("%s: invalid immediate encoding %d\n", __func__, imm);
>+ return AARCH64_BREAK_FAULT;
>+ }
>
> insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst);
>
>@@ -746,7 +769,7 @@ u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_sbfm_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown bitfield encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -759,12 +782,18 @@ u32 aarch64_insn_gen_bitfield(enum aarch64_insn_register dst,
> mask = GENMASK(5, 0);
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>- BUG_ON(immr & ~mask);
>- BUG_ON(imms & ~mask);
>+ if (immr & ~mask) {
>+ pr_err("%s: invalid immr encoding %d\n", __func__, immr);
>+ return AARCH64_BREAK_FAULT;
>+ }
>+ if (imms & ~mask) {
>+ pr_err("%s: invalid imms encoding %d\n", __func__, imms);
>+ return AARCH64_BREAK_FAULT;
>+ }
>
> insn = aarch64_insn_encode_register(AARCH64_INSN_REGTYPE_RD, insn, dst);
>
>@@ -793,23 +822,33 @@ u32 aarch64_insn_gen_movewide(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_movn_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown movewide encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>- BUG_ON(imm & ~(SZ_64K - 1));
>+ if (imm & ~(SZ_64K - 1)) {
>+ pr_err("%s: invalid immediate encoding %d\n", __func__, imm);
>+ return AARCH64_BREAK_FAULT;
>+ }
>
> switch (variant) {
> case AARCH64_INSN_VARIANT_32BIT:
>- BUG_ON(shift != 0 && shift != 16);
>+ if (shift != 0 && shift != 16) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> case AARCH64_INSN_VARIANT_64BIT:
> insn |= AARCH64_INSN_SF_BIT;
>- BUG_ON(shift != 0 && shift != 16 && shift != 32 &&
>- shift != 48);
>+ if (shift != 0 && shift != 16 && shift != 32 && shift != 48) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -843,20 +882,28 @@ u32 aarch64_insn_gen_add_sub_shifted_reg(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_subs_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown add/sub encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
> switch (variant) {
> case AARCH64_INSN_VARIANT_32BIT:
>- BUG_ON(shift & ~(SZ_32 - 1));
>+ if (shift & ~(SZ_32 - 1)) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> case AARCH64_INSN_VARIANT_64BIT:
> insn |= AARCH64_INSN_SF_BIT;
>- BUG_ON(shift & ~(SZ_64 - 1));
>+ if (shift & ~(SZ_64 - 1)) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -885,11 +932,15 @@ u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_rev32_value();
> break;
> case AARCH64_INSN_DATA1_REVERSE_64:
>- BUG_ON(variant != AARCH64_INSN_VARIANT_64BIT);
>+ if (variant != AARCH64_INSN_VARIANT_64BIT) {
>+ pr_err("%s: invalid variant for reverse64 %d\n",
>+ __func__, variant);
>+ return AARCH64_BREAK_FAULT;
>+ }
> insn = aarch64_insn_get_rev64_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown data1 encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -900,7 +951,7 @@ u32 aarch64_insn_gen_data1(enum aarch64_insn_register dst,
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -937,7 +988,7 @@ u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_rorv_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown data2 encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -948,7 +999,7 @@ u32 aarch64_insn_gen_data2(enum aarch64_insn_register dst,
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -976,7 +1027,7 @@ u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_msub_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown data3 encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -987,7 +1038,7 @@ u32 aarch64_insn_gen_data3(enum aarch64_insn_register dst,
> insn |= AARCH64_INSN_SF_BIT;
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>@@ -1037,20 +1088,28 @@ u32 aarch64_insn_gen_logical_shifted_reg(enum aarch64_insn_register dst,
> insn = aarch64_insn_get_bics_value();
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown logical encoding %d\n", __func__, type);
> return AARCH64_BREAK_FAULT;
> }
>
> switch (variant) {
> case AARCH64_INSN_VARIANT_32BIT:
>- BUG_ON(shift & ~(SZ_32 - 1));
>+ if (shift & ~(SZ_32 - 1)) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> case AARCH64_INSN_VARIANT_64BIT:
> insn |= AARCH64_INSN_SF_BIT;
>- BUG_ON(shift & ~(SZ_64 - 1));
>+ if (shift & ~(SZ_64 - 1)) {
>+ pr_err("%s: invalid shift encoding %d\n", __func__,
>+ shift);
>+ return AARCH64_BREAK_FAULT;
>+ }
> break;
> default:
>- BUG_ON(1);
>+ pr_err("%s: unknown variant encoding %d\n", __func__, variant);
> return AARCH64_BREAK_FAULT;
> }
>
>--
>1.9.1
>
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [target-pending 00/12] cxgb4 patch series for cxgbit.ko
From: Nicholas A. Bellinger @ 2016-03-15 5:29 UTC (permalink / raw)
To: Varun Prakash
Cc: target-devel, netdev, davem, swise, indranil, kxie, hariprasad
In-Reply-To: <cover.1457877852.git.varun@chelsio.com>
Hi Varun & Co,
On Sun, 2016-03-13 at 19:49 +0530, Varun Prakash wrote:
> Hi Nicholas,
>
> I am posting cxgb4 patch series as
> suggested by you in following email thread
>
> http://www.spinics.net/lists/target-devel/msg12437.html
>
> This series consists of patches from
> initial cxgb4 series without any change.
>
> Thanks
> Varun
>
Thanks for re-posting iscsi segment offload (ISO) prerequisites as a
stand-alone vxgb4 network driver series.
This -v1 series has been in target-pending/for-next-merge for last
weeks, and encountered one conflict vs. net-next as reported by SFR:
https://lkml.org/lkml/2016/2/29/34
That said, I'm still OK to merge via target-pending to enable post v4.6
iscsi-target developments, as long as DaveM doesn't have an objection or
if he'd prefer to pick them up.
As-is, they still need Acked-by's from the cxgb4 driver maintainer.
Hariprasad, please give your review + ack.
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-15 6:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, jhs, davem
In-Reply-To: <20160314190435.GA23419@nanopsycho.orion>
On 3/14/16, 12:04 PM, Jiri Pirko wrote:
> Mon, Mar 14, 2016 at 07:45:23PM CET, roopa@cumulusnetworks.com wrote:
>> On 3/14/16, 7:51 AM, Jiri Pirko wrote:
>>> Sun, Mar 13, 2016 at 02:56:25AM CET, roopa@cumulusnetworks.com wrote:
>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>
>>>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>>> >from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>>>> returns a lot more than just stats and is expensive in some cases when
>>>> frequent polling for stats from userspace is a common operation.
>>>>
>>>> RTM_GETSTATS is an attempt to provide a light weight netlink message
>>>> to explicity query only link stats from the kernel on an interface.
>>>> The idea is to also keep it extensible so that new kinds of stats can be
>>>> added to it in the future.
>>>>
>>>> This patch adds the following attribute for NETDEV stats:
>>>> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
>>>> [IFLA_STATS_LINK64] = { .len = sizeof(struct rtnl_link_stats64) },
>>>> };
>>>>
>>>> This patch also allows for af family stats (an example af stats for IPV6
>>>> is available with the second patch in the series).
>>>>
>>>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>>>> a single interface or all interfaces with NLM_F_DUMP.
>>>>
>>>> Future possible new types of stat attributes:
>>>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>>>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>>>> vlan, vxlan etc)
>>>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>>>> available via ethtool today)
>>>>
>>>> This patch also declares a filter mask for all stat attributes.
>>>> User has to provide a mask of stats attributes to query. This will be
>>>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>>>
>>>> Without any attributes in the filter_mask, no stats will be returned.
>>>>
>>>> This patch has been tested with modified iproute2 ifstat.
>>>>
>>>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>> ---
[snip]
>>>> +
>>>> +struct if_stats_msg {
>>>> + __u8 family;
>>>> + __u32 ifindex;
>>>> + __u32 filter_mask;
>>> This limit future extension to only 32 groups of stats. I can imagine
>>> that more than that can be added, easily.
>> I thought about that, but it is going to be a while before we run out of the u32.
>> Most of the other stats will be nested like per logical interface stats or
>> per hw stats. If we do run out of them, in the future we could add a netlink
>> attribute for extended filter mask to carry more bits (similar to IFLA_EXT_MASK).
>> I did also start with just having a IFLA_STATS_EXT_MASK like attribute
>> to begin with, but since no stats are dumped by default, having a way to easily specify
>> mask in the hdr will be easier on apps. And this will again be a u32 anyways.
> I believe that using *any* structs to send over netlink is a mistake.
> Netlink is capable to transfer everything using attrs. Easy to compose,
> easy to parse. easy to extend. Couple of more bytes in the message? So what?
> For newly introduced things, I suggest to do this properly.
Jiri, I hear you. I don't prefer structs for netlink attributes either.
But in this case, the struct is for the msg hdr which immediately follows the netlink
header. Its not an attribute value. see my last reply below. rtnetlink_rcv_msg does assume
a struct and family right after the netlink header.
All messages define this struct (see struct ndmsg, or ifinfomsg, rtmsg, br_port_msg etc).
so it is required.
And I do think this struct simplifies a minimum request message and
I have also realized that it really helps if this struct contains basic minimum required
attributes. Ifindex as a filter really helps with RTM_GETSTATS when not used with NLM_F_DUMP
and filter_mask is important for RTM_GETSTATS with NLM_F_DUMP because without
a filter no stats are reported. so, making it part of the base message simplifies the stats
request message from app perspective.
yes the struct cannot be extended, but further extensions can be done as netlink attributes.
>
>
>>
>>> Why don't you use nested
>>> attribute IFLA_STATS_FILTER with flag attributes for every type?
>>> That
>>> would be easily extendable.
>> a u8 for each stats selector seems like an overkill.
>>> Using netlink header struct for this does not look correct to me.
>>> In past, this was done lot of times and turned out to be a problem later.
>>>
>>>
>> I started with not adding it, but rtnetlink rcv handler looks for family
>> in the hdr. And hence all of the messages have a struct header
>> with family as the first field (you can correct me if you find that it is not necessary.)
>>
>>
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-15 6:30 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev, jhs, davem
In-Reply-To: <56E6D224.5020701@6wind.com>
On 3/14/16, 8:00 AM, Nicolas Dichtel wrote:
> Le 13/03/2016 02:56, Roopa Prabhu a écrit :
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>> from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>> returns a lot more than just stats and is expensive in some cases when
>> frequent polling for stats from userspace is a common operation.
>>
>> RTM_GETSTATS is an attempt to provide a light weight netlink message
>> to explicity query only link stats from the kernel on an interface.
>> The idea is to also keep it extensible so that new kinds of stats can be
>> added to it in the future.
>>
>> This patch adds the following attribute for NETDEV stats:
>> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
>> [IFLA_STATS_LINK64] = { .len = sizeof(struct rtnl_link_stats64) },
>> };
>>
>> This patch also allows for af family stats (an example af stats for IPV6
>> is available with the second patch in the series).
>>
>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>> a single interface or all interfaces with NLM_F_DUMP.
>>
>> Future possible new types of stat attributes:
>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>> vlan, vxlan etc)
>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>> available via ethtool today)
>>
>> This patch also declares a filter mask for all stat attributes.
>> User has to provide a mask of stats attributes to query. This will be
>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>
>> Without any attributes in the filter_mask, no stats will be returned.
>>
>> This patch has been tested with modified iproute2 ifstat.
>>
>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
> [snip]
>> diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>> index 249eef9..0840f3e 100644
>> --- a/include/uapi/linux/if_link.h
>> +++ b/include/uapi/linux/if_link.h
> [snip]
>> +enum {
>> + IFLA_STATS_UNSPEC,
>> + IFLA_STATS_LINK64,
>> + IFLA_STATS_INET6,
> IFLA_STATS_INET6 is part on patch #2, it's not used in this patch.
yep, will fix it
>
>> + __IFLA_STATS_MAX,
>> +};
>> +
>> +#define IFLA_STATS_MAX (__IFLA_STATS_MAX - 1)
>> +
>> +#define IFLA_STATS_FILTER_BIT(ATTR) (1 << (ATTR))
>> +
>> #endif /* _UAPI_LINUX_IF_LINK_H */
>> diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
>> index ca764b5..2bbb300 100644
>> --- a/include/uapi/linux/rtnetlink.h
>> +++ b/include/uapi/linux/rtnetlink.h
>> @@ -139,6 +139,13 @@ enum {
>> RTM_GETNSID = 90,
>> #define RTM_GETNSID RTM_GETNSID
>>
>> + RTM_NEWSTATS = 92,
>> +#define RTM_NEWSTATS RTM_NEWSTATS
>> + RTM_DELSTATS = 93,
>> +#define RTM_DELSTATS RTM_DELSTATS
> RTM_DELSTATS is never used.
yeah, i had to define it just because rtnetlink_rcv_msg seems to expect all three to be
there when it tries to check if it is a get msg. But, i could sure not declare this
but make rtnetlink_rcv_msg happy by keeping the GET msg at the right offset.
>
>> + RTM_GETSTATS = 94,
>> +#define RTM_GETSTATS RTM_GETSTATS
>> +
>> __RTM_MAX,
>> #define RTM_MAX (((__RTM_MAX + 3) & ~3) - 1)
>> };
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index d2d9e5e..d1e3d17 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
> [snip]
>> +static noinline size_t if_nlmsg_stats_size(const struct net_device *dev,
>> + u32 filter_mask)
> Why are you using the 'noinline' attribute?
I actually picked it up from if_nlmsg_size ...
>
>> +{
>> + size_t size = 0;
>> +
>> + if (filter_mask & IFLA_STATS_FILTER_BIT(IFLA_STATS_LINK64))
>> + size += nla_total_size(sizeof(struct rtnl_link_stats64));
>> +
>> + size += rtnl_link_get_af_stats_size(dev, filter_mask);
>> +
>> + return size;
>> +}
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-15 6:37 UTC (permalink / raw)
To: Elad Raz
Cc: netdev@vger.kernel.org, jhs@mojatatu.com, davem@davemloft.net,
Jiri Pirko, Ido Schimmel
In-Reply-To: <DB5PR05MB1029A3A82E19D675570A36ACDB880@DB5PR05MB1029.eurprd05.prod.outlook.com>
On 3/14/16, 8:11 AM, Elad Raz wrote:
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>> On Behalf Of Roopa Prabhu
>> Sent: Sunday, March 13, 2016 3:56 AM
>> To: netdev@vger.kernel.org
>> Cc: jhs@mojatatu.com; davem@davemloft.net
>> Subject: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to
>> dump link stats
>>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>
[snip]
>> Future possible new types of stat attributes:
>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like
>> bridge,
>> vlan, vxlan etc)
>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>> available via ethtool today)
>>
>> This patch also declares a filter mask for all stat attributes.
>> User has to provide a mask of stats attributes to query. This will be
>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>
>> Without any attributes in the filter_mask, no stats will be returned.
>>
>> This patch has been tested with modified iproute2 ifstat.
>>
>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>>
[snip]
>> diff --git a/include/uapi/linux/rtnetlink.h
>> b/include/uapi/linux/rtnetlink.h index ca764b5..2bbb300 100644
>> --- a/include/uapi/linux/rtnetlink.h
>> +++ b/include/uapi/linux/rtnetlink.h
>> @@ -139,6 +139,13 @@ enum {
>> RTM_GETNSID = 90,
>> #define RTM_GETNSID RTM_GETNSID
>>
>> + RTM_NEWSTATS = 92,
>> +#define RTM_NEWSTATS RTM_NEWSTATS
> I think that RTM_NEWSTATS and RTM_DELSTATS aren't good names, since user doesn't add/del statistics but only query.
> Maybe just stay with RTM_GETSTATS and the message back to user will be RTM_GETSTATS as well?
yeah, i defined all of these because rtnetlink_rcv_msg seems to expect all three to be
there when it tries to check if it is a get msg. But, i could sure not declare this
but make rtnetlink_rcv_msg happy by keeping the GET msg at the right offset.
The RTM_NEWSTATS i thought i should leave it in there because the original thought from
jamal also had periodic stats notification to user-space...which should be RTM_NEWSTATS.
But, then again that can be added when we implement that function.
>
>> + RTM_DELSTATS = 93,
>> +#define RTM_DELSTATS RTM_DELSTATS
> This is not in used
>
>
same response as above. will drop some of them in v2.
^ permalink raw reply
* Re: [PATCH V2 net 0/6] net: hns: hns driver updates
From: Daode Huang @ 2016-03-15 6:43 UTC (permalink / raw)
To: David Miller
Cc: liguozhu, Yisen.Zhuang, linux-kernel, linux-arm-kernel, netdev,
linuxarm, salil.mehta, kenneth-lee-2012, xuwei5, lisheng011,
yankejian
In-Reply-To: <20160314.224511.688178587092115078.davem@davemloft.net>
hi Dave,
Thanks for your reply, I am so sorry to interrupt your work.
Yes, the patch set should be reviewed by all the other developers.
I should not only ask you to review the patch.
I will resend all these patch after 4.6-rc-1 is released.
Thanks.
Daode.
.
On 2016/3/15 10:45, David Miller wrote:
> From: Daode Huang <huangdaode@hisilicon.com>
> Date: Tue, 15 Mar 2016 09:56:02 +0800
>
>> Could you please help me to review this patch set?
> I am not reviewing anything until you guys sort out your submission
> scheme, and resend these fresh using that central maintainer.
>
> I am also not the only person in the world who is supposed to review
> all of this stuff, other developers need to help with the review
> process as well.
>
> So it is never appropriate to ask me, and only me, to review your
> work.
>
> Thanks.
>
> .
>
^ permalink raw reply
* Re: pull request (net): ipsec 2016-03-10
From: Steffen Klassert @ 2016-03-15 6:59 UTC (permalink / raw)
To: David Miller; +Cc: herbert, netdev
In-Reply-To: <20160314.152129.2264257224526134835.davem@davemloft.net>
On Mon, Mar 14, 2016 at 03:21:29PM -0400, David Miller wrote:
>
> Patches 4 and 5 were given some feedback, please fix those issues up and
> respin this pull request.
I did a respin on my testing branch already, but new pmtu
problems popped up. So I want to hold off the new pull
request until everything is fixed.
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-15 7:02 UTC (permalink / raw)
To: David Miller; +Cc: jiri, netdev, jhs
In-Reply-To: <20160314.155640.1574437783302725000.davem@davemloft.net>
On 3/14/16, 12:56 PM, David Miller wrote:
> From: Jiri Pirko <jiri@resnulli.us>
> Date: Mon, 14 Mar 2016 20:04:35 +0100
>
>> I believe that using *any* structs to send over netlink is a mistake.
>> Netlink is capable to transfer everything using attrs. Easy to compose,
>> easy to parse. easy to extend. Couple of more bytes in the message? So what?
>> For newly introduced things, I suggest to do this properly.
> It is not so straight-forward.
>
> What to put into the header is a tradeoff.
>
> The most basic use cases should be as efficient as possible, and if we
> can put reasonable knobs into the base commend header we should do that
> as avoiding attribute processing makes things faster.
yes, i have recently realized this after looking at all other message
types and the userspace part of it. It does make the default message much simpler.
>
> And I think in this case it is reasonable to put the mask in there.
>
> The only problem I see with this series is the naming of the netlink
> command (it isn't a "new" operation, and the "del" is unused).
I just replied to the other responses on this: I did declare all three because
rtnetlink_rcv_msg seems to expect the get message at a particular offset
(when it derives kind from nlmsg_type). But, i can fix it accordingly.
>
> Maybe the suggestion to use just "GET" as the name is ok.
I am thinking RTM_NEWSTATS is ok here. Because from userspace you are looking at message per interface
as a separate stats object. It also adheres to existing convention.
Besides, jamals original request/suggestion also had periodic stats notification to user-space...,
in which case it would be more appropriate to use RTM_NEWSTATS (if we implement it in the future ofcourse).
And from userspace perspective, dumps and notifications should come in with the same msg type.
userspace sees it as a stats message and does not care if it came as part of a dump or a notification.
also, user space netlink caches expect this (i work with libnl a lot and it is based on this assumption).
so, RTM_NEWSTATS seems more appropriate here.
But, if you have stronger reasons for RTM_GETSTATS, sure, pls let me know.
Thanks,
Roopa
^ permalink raw reply
* Re: [target-pending 00/12] cxgb4 patch series for cxgbit.ko
From: Hariprasad Shenai @ 2016-03-15 7:04 UTC (permalink / raw)
To: Nicholas A. Bellinger
Cc: Varun Prakash, target-devel, netdev, davem, swise, indranil, kxie
In-Reply-To: <1458019751.15882.31.camel@haakon3.risingtidesystems.com>
On Mon, Mar 14, 2016 at 22:29:11 -0700, Nicholas A. Bellinger wrote:
> Hi Varun & Co,
>
> On Sun, 2016-03-13 at 19:49 +0530, Varun Prakash wrote:
> > Hi Nicholas,
> >
> > I am posting cxgb4 patch series as
> > suggested by you in following email thread
> >
> > http://www.spinics.net/lists/target-devel/msg12437.html
> >
> > This series consists of patches from
> > initial cxgb4 series without any change.
> >
> > Thanks
> > Varun
> >
>
> Thanks for re-posting iscsi segment offload (ISO) prerequisites as a
> stand-alone vxgb4 network driver series.
>
> This -v1 series has been in target-pending/for-next-merge for last
> weeks, and encountered one conflict vs. net-next as reported by SFR:
>
> https://lkml.org/lkml/2016/2/29/34
>
> That said, I'm still OK to merge via target-pending to enable post v4.6
> iscsi-target developments, as long as DaveM doesn't have an objection or
> if he'd prefer to pick them up.
>
> As-is, they still need Acked-by's from the cxgb4 driver maintainer.
>
> Hariprasad, please give your review + ack.
>
The entire series looks good.
Acked-by: Hariprasad Shenai <hariprasad@chelsio.com>
^ permalink raw reply
* Re: [target-pending 00/12] cxgb4 patch series for cxgbit.ko
From: Nicholas A. Bellinger @ 2016-03-15 7:13 UTC (permalink / raw)
To: Hariprasad Shenai
Cc: Varun Prakash, target-devel, netdev, davem, swise, indranil, kxie
In-Reply-To: <20160315070427.GA8122@hari-Latitude-E5550>
On Tue, 2016-03-15 at 12:34 +0530, Hariprasad Shenai wrote:
> On Mon, Mar 14, 2016 at 22:29:11 -0700, Nicholas A. Bellinger wrote:
> > Hi Varun & Co,
> >
> > On Sun, 2016-03-13 at 19:49 +0530, Varun Prakash wrote:
> > > Hi Nicholas,
> > >
> > > I am posting cxgb4 patch series as
> > > suggested by you in following email thread
> > >
> > > http://www.spinics.net/lists/target-devel/msg12437.html
> > >
> > > This series consists of patches from
> > > initial cxgb4 series without any change.
> > >
> > > Thanks
> > > Varun
> > >
> >
> > Thanks for re-posting iscsi segment offload (ISO) prerequisites as a
> > stand-alone vxgb4 network driver series.
> >
> > This -v1 series has been in target-pending/for-next-merge for last
> > weeks, and encountered one conflict vs. net-next as reported by SFR:
> >
> > https://lkml.org/lkml/2016/2/29/34
> >
> > That said, I'm still OK to merge via target-pending to enable post v4.6
> > iscsi-target developments, as long as DaveM doesn't have an objection or
> > if he'd prefer to pick them up.
> >
> > As-is, they still need Acked-by's from the cxgb4 driver maintainer.
> >
> > Hariprasad, please give your review + ack.
> >
>
> The entire series looks good.
>
> Acked-by: Hariprasad Shenai <hariprasad@chelsio.com>
>
cxgb4 driver ACKs applied to target-pending/for-next-merge.
Thanks Hariprasad.
^ permalink raw reply
* [patch 1/2 net-next] mediatek: checking for IS_ERR() instead of NULL
From: Dan Carpenter @ 2016-03-15 7:18 UTC (permalink / raw)
To: Felix Fietkau, John Crispin
Cc: Matthias Brugger, netdev, linux-mediatek, kernel-janitors
of_phy_connect() returns NULL on error, it never returns error pointers.
Fixes: 656e705243fd ('net-next: mediatek: add support for MT7623 ethernet')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index ba3afa5..9759fe5 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -186,9 +186,9 @@ static int mtk_phy_connect_node(struct mtk_eth *eth, struct mtk_mac *mac,
phydev = of_phy_connect(eth->netdev[mac->id], phy_node,
mtk_phy_link_adjust, 0, phy_mode);
- if (IS_ERR(phydev)) {
+ if (!phydev) {
dev_err(eth->dev, "could not connect to PHY\n");
- return PTR_ERR(phydev);
+ return -ENODEV;
}
dev_info(eth->dev,
^ permalink raw reply related
* [patch 2/2 net-next] mediatek: unlock on error in mtk_tx_map()
From: Dan Carpenter @ 2016-03-15 7:19 UTC (permalink / raw)
To: Felix Fietkau, John Crispin
Cc: Matthias Brugger, netdev, linux-mediatek, kernel-janitors
There was a missing unlock on the error path.
Fixes: 656e705243fd ('net-next: mediatek: add support for MT7623 ethernet')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 9759fe5..c2c2e206 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -661,6 +661,8 @@ err_dma:
itxd = mtk_qdma_phys_to_virt(ring, itxd->txd2);
} while (itxd != txd);
+ spin_unlock_irqrestore(ð->page_lock, flags);
+
return -ENOMEM;
}
^ permalink raw reply related
* Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement
From: Tomeu Vizoso @ 2016-03-15 7:23 UTC (permalink / raw)
To: Giuseppe CAVALLARO
Cc: Dinh Nguyen, Andreas Färber, Fabrice GASNIER,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Heiko Stübner, netdev-u79uwXL29TY76Z2rM5mHXA,
open list:ARM/Rockchip SoC..., LAKML, Gabriel Fernandez,
Alexandre TORGUE, Frank Schäfer, LKML
In-Reply-To: <56E6E4B0.8060408-qxv4g6HH51o@public.gmane.org>
On 14 March 2016 at 17:20, Giuseppe CAVALLARO <peppe.cavallaro-qxv4g6HH51o@public.gmane.org> wrote:
> Hi Tomeu
>
> On 3/14/2016 12:43 PM, Tomeu Vizoso wrote:
>>
>> Hi Peppe,
>>
>> with that patch I don't see any difference at all in my setup.
>>
>> So to be clear, with these commits on top of next-20160314, I still
>> get the hang during boot:
>>
>> 209afef6f0cd ARM: dts: rockchip: Add mdio node to ethernet node
>> 2315acc6cf7f Revert "stmmac: first frame prep at the end of xmit routine"
>> b5e08e810c63 stmmac: fix tx prepare for normal desc
>> 37c15a31d850 i2c: immediately mark ourselves as registered
>> 4342eec3c5a2 Add linux-next specific files for 20160314
>>
>> [ 27.521026] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:303
>> dev_watchdog+0x284/0x288
>> [ 27.529460] NETDEV WATCHDOG: eth0 (rk_gmac-dwmac): transmit queue 0
>> timed out
>
>
> I do not reproduce the WATCHDOG but i am continuing to look at the code
> to understand if normal descriptor management is ok or not. I keep you
> informed.
>
> Just an info, did you test with 2315acc6cf7f included? Just to
> understand if it is introducing a problem. It works in case of
> enhanced descriptors are used instead of.
>
>>
>>
>> https://git.collabora.com/cgit/user/tomeu/linux.git/log/?h=broken-eth-on-rock2
>
>
> thx I will take a look at this
Thanks.
Btw, I have rebased on top of 4.5 this morning and I have noticed that
88f8b1bb41c6 ("stmmac: Fix 'eth0: No PHY found' regression") got in
there, so I guess we have now a bunch of boards with broken network on
that release :(
Regards,
Tomeu
> Regards
> Peppe
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch 1/2 net-next] mediatek: checking for IS_ERR() instead of NULL
From: John Crispin @ 2016-03-15 7:27 UTC (permalink / raw)
To: Dan Carpenter, Felix Fietkau
Cc: Matthias Brugger, netdev, kernel-janitors, linux-mediatek
In-Reply-To: <20160315071849.GH13560@mwanda>
On 15/03/2016 08:18, Dan Carpenter wrote:
> of_phy_connect() returns NULL on error, it never returns error pointers.
>
> Fixes: 656e705243fd ('net-next: mediatek: add support for MT7623 ethernet')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
Acked-by: John Crispin <blogic@openwrt.org>
Thanks !
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index ba3afa5..9759fe5 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -186,9 +186,9 @@ static int mtk_phy_connect_node(struct mtk_eth *eth, struct mtk_mac *mac,
>
> phydev = of_phy_connect(eth->netdev[mac->id], phy_node,
> mtk_phy_link_adjust, 0, phy_mode);
> - if (IS_ERR(phydev)) {
> + if (!phydev) {
> dev_err(eth->dev, "could not connect to PHY\n");
> - return PTR_ERR(phydev);
> + return -ENODEV;
> }
>
> dev_info(eth->dev,
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
^ permalink raw reply
* Re: [patch 2/2 net-next] mediatek: unlock on error in mtk_tx_map()
From: John Crispin @ 2016-03-15 7:27 UTC (permalink / raw)
To: Dan Carpenter, Felix Fietkau
Cc: Matthias Brugger, netdev, kernel-janitors, linux-mediatek
In-Reply-To: <20160315071904.GI13560@mwanda>
On 15/03/2016 08:19, Dan Carpenter wrote:
> There was a missing unlock on the error path.
>
> Fixes: 656e705243fd ('net-next: mediatek: add support for MT7623 ethernet')
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
Acked-by: John Crispin <blogic@openwrt.org>
Thanks !
> diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> index 9759fe5..c2c2e206 100644
> --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
> @@ -661,6 +661,8 @@ err_dma:
> itxd = mtk_qdma_phys_to_virt(ring, itxd->txd2);
> } while (itxd != txd);
>
> + spin_unlock_irqrestore(ð->page_lock, flags);
> +
> return -ENOMEM;
> }
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: Jiri Pirko @ 2016-03-15 7:28 UTC (permalink / raw)
To: roopa; +Cc: netdev, jhs, davem
In-Reply-To: <56E7AA96.8030305@cumulusnetworks.com>
Tue, Mar 15, 2016 at 07:24:22AM CET, roopa@cumulusnetworks.com wrote:
>On 3/14/16, 12:04 PM, Jiri Pirko wrote:
>> Mon, Mar 14, 2016 at 07:45:23PM CET, roopa@cumulusnetworks.com wrote:
>>> On 3/14/16, 7:51 AM, Jiri Pirko wrote:
>>>> Sun, Mar 13, 2016 at 02:56:25AM CET, roopa@cumulusnetworks.com wrote:
>>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>>
>>>>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>>>> >from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>>>>> returns a lot more than just stats and is expensive in some cases when
>>>>> frequent polling for stats from userspace is a common operation.
>>>>>
>>>>> RTM_GETSTATS is an attempt to provide a light weight netlink message
>>>>> to explicity query only link stats from the kernel on an interface.
>>>>> The idea is to also keep it extensible so that new kinds of stats can be
>>>>> added to it in the future.
>>>>>
>>>>> This patch adds the following attribute for NETDEV stats:
>>>>> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
>>>>> [IFLA_STATS_LINK64] = { .len = sizeof(struct rtnl_link_stats64) },
>>>>> };
>>>>>
>>>>> This patch also allows for af family stats (an example af stats for IPV6
>>>>> is available with the second patch in the series).
>>>>>
>>>>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>>>>> a single interface or all interfaces with NLM_F_DUMP.
>>>>>
>>>>> Future possible new types of stat attributes:
>>>>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>>>>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>>>>> vlan, vxlan etc)
>>>>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>>>>> available via ethtool today)
>>>>>
>>>>> This patch also declares a filter mask for all stat attributes.
>>>>> User has to provide a mask of stats attributes to query. This will be
>>>>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>>>>
>>>>> Without any attributes in the filter_mask, no stats will be returned.
>>>>>
>>>>> This patch has been tested with modified iproute2 ifstat.
>>>>>
>>>>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>> ---
>[snip]
>>>>> +
>>>>> +struct if_stats_msg {
>>>>> + __u8 family;
>>>>> + __u32 ifindex;
>>>>> + __u32 filter_mask;
>>>> This limit future extension to only 32 groups of stats. I can imagine
>>>> that more than that can be added, easily.
>>> I thought about that, but it is going to be a while before we run out of the u32.
>>> Most of the other stats will be nested like per logical interface stats or
>>> per hw stats. If we do run out of them, in the future we could add a netlink
>>> attribute for extended filter mask to carry more bits (similar to IFLA_EXT_MASK).
>>> I did also start with just having a IFLA_STATS_EXT_MASK like attribute
>>> to begin with, but since no stats are dumped by default, having a way to easily specify
>>> mask in the hdr will be easier on apps. And this will again be a u32 anyways.
>> I believe that using *any* structs to send over netlink is a mistake.
>> Netlink is capable to transfer everything using attrs. Easy to compose,
>> easy to parse. easy to extend. Couple of more bytes in the message? So what?
>> For newly introduced things, I suggest to do this properly.
>
>Jiri, I hear you. I don't prefer structs for netlink attributes either.
Looks like you clearly prefer structs, otherwise we wouldn't be having
this discussion.
>But in this case, the struct is for the msg hdr which immediately follows the netlink
>header. Its not an attribute value. see my last reply below. rtnetlink_rcv_msg does assume
>a struct and family right after the netlink header.
>All messages define this struct (see struct ndmsg, or ifinfomsg, rtmsg, br_port_msg etc).
>so it is required.
Okay. So let's kee[ that struct as small as possible. Containing only
family and ifindex. That should be enough.
>
>And I do think this struct simplifies a minimum request message and
>I have also realized that it really helps if this struct contains basic minimum required
>attributes. Ifindex as a filter really helps with RTM_GETSTATS when not used with NLM_F_DUMP
>and filter_mask is important for RTM_GETSTATS with NLM_F_DUMP because without
>a filter no stats are reported. so, making it part of the base message simplifies the stats
>request message from app perspective.
I don't understand this argument. As I wrote earlier, user app can
easily specify filter mask by flag attrs. It is very easy.
>
>yes the struct cannot be extended, but further extensions can be done as netlink attributes.
Exactly, we now now that this is not extendable, we know that if will
likely get extended, yet you still argue for the non-extendable
approach. I don't get it, sorry :(
>
>
>
>
>>
>>
>>>
>>>> Why don't you use nested
>>>> attribute IFLA_STATS_FILTER with flag attributes for every type?
>>>> That
>>>> would be easily extendable.
>>> a u8 for each stats selector seems like an overkill.
>>>> Using netlink header struct for this does not look correct to me.
>>>> In past, this was done lot of times and turned out to be a problem later.
>>>>
>>>>
>>> I started with not adding it, but rtnetlink rcv handler looks for family
>>> in the hdr. And hence all of the messages have a struct header
>>> with family as the first field (you can correct me if you find that it is not necessary.)
>>>
>>>
>
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-03-14
From: Kalle Valo @ 2016-03-15 7:34 UTC (permalink / raw)
To: David Miller
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160314.121528.1217892668324346880.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Date: Mon, 14 Mar 2016 10:31:48 +0200
>
>> I know I'm late now that merge window was opened yesterday but here's
>> one more set of patches I would like to get to 4.6 still. There isn't
>> anything controversial so I hope this should be still safe to pull. The
>> patches have been in linux-next since Friday and I haven't seen any
>> reports about issues. But if you think it's too late just let me know
>> and I'll resubmit these for 4.7.
>>
>> The most notable part here of course is rtl8xxxu with over 100 patches.
>> As the driver is new and under heavy development I think they are ok to
>> take still. Otherwise there are mostly fixes with an exception of adding
>> a new debugfs file to wl18xx.
>>
>> Please let me know if you have any problems.
>
> Pulled, thanks.
Great, thanks a lot.
> I really like Jes's work and I wish you had integrated it several
> months ago, instead of sloshing him needlessly through a non-stop
> cycle of very nit-picky issues, just FYI.
I also like his work and I'm sorry for being too nit-picky. I have tried
to be extra careful with the patches I send to you, especially with new
drivers, and I guess I have been too pedantic. I'll try to lower the bar
to a more reasonable level.
But I actually started to wonder what you actually mean and checked the
dates of initial rtl8xxxu submission from patchwork:
2015-08-29 v1
2015-08-30 v2
2015-10-15 v3
2015-10-21 applied 26f1fad29ad9 to w-d-next for v4.4
Two months is quite long for a good driver like this but IIRC the
initial commit was pending wireless-drivers directory reorganisation,
and that just took too long on my side.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/2] rtnetlink: add new RTM_GETSTATS message to dump link stats
From: roopa @ 2016-03-15 7:38 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, jhs, davem
In-Reply-To: <20160315072856.GA2263@nanopsycho.orion>
On 3/15/16, 12:28 AM, Jiri Pirko wrote:
> Tue, Mar 15, 2016 at 07:24:22AM CET, roopa@cumulusnetworks.com wrote:
>> On 3/14/16, 12:04 PM, Jiri Pirko wrote:
>>> Mon, Mar 14, 2016 at 07:45:23PM CET, roopa@cumulusnetworks.com wrote:
>>>> On 3/14/16, 7:51 AM, Jiri Pirko wrote:
>>>>> Sun, Mar 13, 2016 at 02:56:25AM CET, roopa@cumulusnetworks.com wrote:
>>>>>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>>>
>>>>>> This patch adds a new RTM_GETSTATS message to query link stats via netlink
>>>>> >from the kernel. RTM_NEWLINK also dumps stats today, but RTM_NEWLINK
>>>>>> returns a lot more than just stats and is expensive in some cases when
>>>>>> frequent polling for stats from userspace is a common operation.
>>>>>>
>>>>>> RTM_GETSTATS is an attempt to provide a light weight netlink message
>>>>>> to explicity query only link stats from the kernel on an interface.
>>>>>> The idea is to also keep it extensible so that new kinds of stats can be
>>>>>> added to it in the future.
>>>>>>
>>>>>> This patch adds the following attribute for NETDEV stats:
>>>>>> struct nla_policy ifla_stats_policy[IFLA_STATS_MAX + 1] = {
>>>>>> [IFLA_STATS_LINK64] = { .len = sizeof(struct rtnl_link_stats64) },
>>>>>> };
>>>>>>
>>>>>> This patch also allows for af family stats (an example af stats for IPV6
>>>>>> is available with the second patch in the series).
>>>>>>
>>>>>> Like any other rtnetlink message, RTM_GETSTATS can be used to get stats of
>>>>>> a single interface or all interfaces with NLM_F_DUMP.
>>>>>>
>>>>>> Future possible new types of stat attributes:
>>>>>> - IFLA_MPLS_STATS (nested. for mpls/mdev stats)
>>>>>> - IFLA_EXTENDED_STATS (nested. extended software netdev stats like bridge,
>>>>>> vlan, vxlan etc)
>>>>>> - IFLA_EXTENDED_HW_STATS (nested. extended hardware stats which are
>>>>>> available via ethtool today)
>>>>>>
>>>>>> This patch also declares a filter mask for all stat attributes.
>>>>>> User has to provide a mask of stats attributes to query. This will be
>>>>>> specified in a new hdr 'struct if_stats_msg' for stats messages.
>>>>>>
>>>>>> Without any attributes in the filter_mask, no stats will be returned.
>>>>>>
>>>>>> This patch has been tested with modified iproute2 ifstat.
>>>>>>
>>>>>> Suggested-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>>>>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>>>>>> ---
>> [snip]
>>>>>> +
>>>>>> +struct if_stats_msg {
>>>>>> + __u8 family;
>>>>>> + __u32 ifindex;
>>>>>> + __u32 filter_mask;
>>>>> This limit future extension to only 32 groups of stats. I can imagine
>>>>> that more than that can be added, easily.
>>>> I thought about that, but it is going to be a while before we run out of the u32.
>>>> Most of the other stats will be nested like per logical interface stats or
>>>> per hw stats. If we do run out of them, in the future we could add a netlink
>>>> attribute for extended filter mask to carry more bits (similar to IFLA_EXT_MASK).
>>>> I did also start with just having a IFLA_STATS_EXT_MASK like attribute
>>>> to begin with, but since no stats are dumped by default, having a way to easily specify
>>>> mask in the hdr will be easier on apps. And this will again be a u32 anyways.
>>> I believe that using *any* structs to send over netlink is a mistake.
>>> Netlink is capable to transfer everything using attrs. Easy to compose,
>>> easy to parse. easy to extend. Couple of more bytes in the message? So what?
>>> For newly introduced things, I suggest to do this properly.
>> Jiri, I hear you. I don't prefer structs for netlink attributes either.
> Looks like you clearly prefer structs, otherwise we wouldn't be having
> this discussion.
>
>
>> But in this case, the struct is for the msg hdr which immediately follows the netlink
>> header. Its not an attribute value. see my last reply below. rtnetlink_rcv_msg does assume
>> a struct and family right after the netlink header.
>> All messages define this struct (see struct ndmsg, or ifinfomsg, rtmsg, br_port_msg etc).
>> so it is required.
> Okay. So let's kee[ that struct as small as possible. Containing only
> family and ifindex. That should be enough.
how does it matter if we have reached an agreement that the struct is required ?.
unlike other messages, a filter_mask is an important and must attribute for
stats. If you are worried about us running out of bits in u32, the netlink attribute you will
define for the filter_mask will also be u32 to begin with.
So, i don't understand what we gain from making filter_mask a separate attribute right now.
I would have agreed with your argument if filter_mask was optional.
>> And I do think this struct simplifies a minimum request message and
>> I have also realized that it really helps if this struct contains basic minimum required
>> attributes. Ifindex as a filter really helps with RTM_GETSTATS when not used with NLM_F_DUMP
>> and filter_mask is important for RTM_GETSTATS with NLM_F_DUMP because without
>> a filter no stats are reported. so, making it part of the base message simplifies the stats
>> request message from app perspective.
> I don't understand this argument. As I wrote earlier, user app can
> easily specify filter mask by flag attrs. It is very easy.
>
>
>> yes the struct cannot be extended, but further extensions can be done as netlink attributes.
> Exactly, we now now that this is not extendable, we know that if will
> likely get extended, yet you still argue for the non-extendable
> approach. I don't get it, sorry :(
>
^ permalink raw reply
* [PATCH 1/1] net: stmmac: Don't search for phys if mdio node is defined.
From: Phil Reid @ 2016-03-15 7:34 UTC (permalink / raw)
To: peppe.cavallaro, netdev; +Cc: Phil Reid
In-Reply-To: <1458027273-127737-1-git-send-email-preid@electromag.com.au>
If a dt mdio entry has been added least assume that we wont
search for phys attached. The DT and of_mdiobus_register already do
this. This stops DSA phys being found and phys created for them, as
this is handled by the DSA driver.
Signed-off-by: Phil Reid <preid@electromag.com.au>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 3f5512f..06704ca 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -235,6 +235,9 @@ int stmmac_mdio_register(struct net_device *ndev)
goto bus_register_fail;
}
+ if (priv->plat->phy_node || mdio_node)
+ goto bus_register_done;
+
found = 0;
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phydev = mdiobus_get_phy(new_bus, addr);
@@ -290,6 +293,7 @@ int stmmac_mdio_register(struct net_device *ndev)
return -ENODEV;
}
+bus_register_done:
priv->mii = new_bus;
return 0;
--
1.8.3.1
^ permalink raw reply related
* [PATCH 0/1] net: stmmac: Don't search for phys if mdio node is defined.
From: Phil Reid @ 2016-03-15 7:34 UTC (permalink / raw)
To: peppe.cavallaro, netdev; +Cc: Phil Reid
If a dt mdio entry has been added least assume that we wont
search for phys attached. The DT and of_mdiobus_register already do
this. This stops DSA phys being found and phys created for them, as
this is handled by the DSA driver.
Note: I'm not 100% sure that priv->plat->phy_node should be included
in the conditional here. But it looks like if a phy-handle is used
then we don't want to search for phys.
Phil Reid (1):
net: stmmac: Don't search for phys if mdio node is defined.
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 4 ++++
1 file changed, 4 insertions(+)
--
1.8.3.1
^ 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