* [PATCH V2 net-next 1/8] net: hns3: Add support for serdes loopback selftest
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm, Yunsheng Lin
In-Reply-To: <20180814161319.16392-1-salil.mehta@huawei.com>
From: Peng Li <lipeng321@huawei.com>
This patch adds support for serdes loopback selftest in hns3
driver.
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Peng Li <lipeng321@huawei.com>
Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
---
Patch V2: Fixed comments from Davis S Miller
@Link, https://lkml.org/lkml/2018/8/13/385
Patch V1: Initial Submit
---
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 11 +++--
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 12 +++++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 57 +++++++++++++++++++++-
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 80ba95d..f70ee69 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -53,7 +53,7 @@ static const struct hns3_stats hns3_rxq_stats[] = {
#define HNS3_TQP_STATS_COUNT (HNS3_TXQ_STATS_COUNT + HNS3_RXQ_STATS_COUNT)
-#define HNS3_SELF_TEST_TPYE_NUM 1
+#define HNS3_SELF_TEST_TYPE_NUM 2
#define HNS3_NIC_LB_TEST_PKT_NUM 1
#define HNS3_NIC_LB_TEST_RING_ID 0
#define HNS3_NIC_LB_TEST_PACKET_SIZE 128
@@ -78,6 +78,7 @@ static int hns3_lp_setup(struct net_device *ndev, enum hnae3_loop loop, bool en)
return -EOPNOTSUPP;
switch (loop) {
+ case HNAE3_MAC_INTER_LOOP_SERDES:
case HNAE3_MAC_INTER_LOOP_MAC:
ret = h->ae_algo->ops->set_loopback(h, loop, en);
break;
@@ -287,7 +288,7 @@ static void hns3_self_test(struct net_device *ndev,
{
struct hns3_nic_priv *priv = netdev_priv(ndev);
struct hnae3_handle *h = priv->ae_handle;
- int st_param[HNS3_SELF_TEST_TPYE_NUM][2];
+ int st_param[HNS3_SELF_TEST_TYPE_NUM][2];
bool if_running = netif_running(ndev);
#if IS_ENABLED(CONFIG_VLAN_8021Q)
bool dis_vlan_filter;
@@ -303,6 +304,10 @@ static void hns3_self_test(struct net_device *ndev,
st_param[HNAE3_MAC_INTER_LOOP_MAC][1] =
h->flags & HNAE3_SUPPORT_MAC_LOOPBACK;
+ st_param[HNAE3_MAC_INTER_LOOP_SERDES][0] = HNAE3_MAC_INTER_LOOP_SERDES;
+ st_param[HNAE3_MAC_INTER_LOOP_SERDES][1] =
+ h->flags & HNAE3_SUPPORT_SERDES_LOOPBACK;
+
if (if_running)
dev_close(ndev);
@@ -316,7 +321,7 @@ static void hns3_self_test(struct net_device *ndev,
set_bit(HNS3_NIC_STATE_TESTING, &priv->state);
- for (i = 0; i < HNS3_SELF_TEST_TPYE_NUM; i++) {
+ for (i = 0; i < HNS3_SELF_TEST_TYPE_NUM; i++) {
enum hnae3_loop loop_type = (enum hnae3_loop)st_param[i][0];
if (!st_param[i][1])
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
index cd0a4f2..821d4c2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h
@@ -94,6 +94,7 @@ enum hclge_opcode_type {
HCLGE_OPC_QUERY_LINK_STATUS = 0x0307,
HCLGE_OPC_CONFIG_MAX_FRM_SIZE = 0x0308,
HCLGE_OPC_CONFIG_SPEED_DUP = 0x0309,
+ HCLGE_OPC_SERDES_LOOPBACK = 0x0315,
/* PFC/Pause commands */
HCLGE_OPC_CFG_MAC_PAUSE_EN = 0x0701,
@@ -775,6 +776,17 @@ struct hclge_reset_cmd {
u8 fun_reset_vfid;
u8 rsv[22];
};
+
+#define HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B BIT(0)
+#define HCLGE_CMD_SERDES_DONE_B BIT(0)
+#define HCLGE_CMD_SERDES_SUCCESS_B BIT(1)
+struct hclge_serdes_lb_cmd {
+ u8 mask;
+ u8 enable;
+ u8 result;
+ u8 rsv[21];
+};
+
#define HCLGE_DEFAULT_TX_BUF 0x4000 /* 16k bytes */
#define HCLGE_TOTAL_PKT_BUF 0x108000 /* 1.03125M bytes */
#define HCLGE_DEFAULT_DV 0xA000 /* 40k byte */
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index fc813b7..9209122 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -787,9 +787,10 @@ static int hclge_get_sset_count(struct hnae3_handle *handle, int stringset)
hdev->hw.mac.speed == HCLGE_MAC_SPEED_1G) {
count += 1;
handle->flags |= HNAE3_SUPPORT_MAC_LOOPBACK;
- } else {
- count = -EOPNOTSUPP;
}
+
+ count++;
+ handle->flags |= HNAE3_SUPPORT_SERDES_LOOPBACK;
} else if (stringset == ETH_SS_STATS) {
count = ARRAY_SIZE(g_mac_stats_string) +
ARRAY_SIZE(g_all_32bit_stats_string) +
@@ -3670,6 +3671,55 @@ static int hclge_set_mac_loopback(struct hclge_dev *hdev, bool en)
return ret;
}
+static int hclge_set_serdes_loopback(struct hclge_dev *hdev, bool en)
+{
+#define HCLGE_SERDES_RETRY_MS 10
+#define HCLGE_SERDES_RETRY_NUM 100
+ struct hclge_serdes_lb_cmd *req;
+ struct hclge_desc desc;
+ int ret, i = 0;
+
+ req = (struct hclge_serdes_lb_cmd *)&desc.data[0];
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_SERDES_LOOPBACK, false);
+
+ if (en) {
+ req->enable = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ req->mask = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ } else {
+ req->mask = HCLGE_CMD_SERDES_SERIAL_INNER_LOOP_B;
+ }
+
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "serdes loopback set fail, ret = %d\n", ret);
+ return ret;
+ }
+
+ do {
+ msleep(HCLGE_SERDES_RETRY_MS);
+ hclge_cmd_setup_basic_desc(&desc, HCLGE_OPC_SERDES_LOOPBACK,
+ true);
+ ret = hclge_cmd_send(&hdev->hw, &desc, 1);
+ if (ret) {
+ dev_err(&hdev->pdev->dev,
+ "serdes loopback get, ret = %d\n", ret);
+ return ret;
+ }
+ } while (++i < HCLGE_SERDES_RETRY_NUM &&
+ !(req->result & HCLGE_CMD_SERDES_DONE_B));
+
+ if (!(req->result & HCLGE_CMD_SERDES_DONE_B)) {
+ dev_err(&hdev->pdev->dev, "serdes loopback set timeout\n");
+ return -EBUSY;
+ } else if (!(req->result & HCLGE_CMD_SERDES_SUCCESS_B)) {
+ dev_err(&hdev->pdev->dev, "serdes loopback set failed in fw\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int hclge_set_loopback(struct hnae3_handle *handle,
enum hnae3_loop loop_mode, bool en)
{
@@ -3681,6 +3731,9 @@ static int hclge_set_loopback(struct hnae3_handle *handle,
case HNAE3_MAC_INTER_LOOP_MAC:
ret = hclge_set_mac_loopback(hdev, en);
break;
+ case HNAE3_MAC_INTER_LOOP_SERDES:
+ ret = hclge_set_serdes_loopback(hdev, en);
+ break;
default:
ret = -ENOTSUPP;
dev_err(&hdev->pdev->dev,
--
2.7.4
^ permalink raw reply related
* [PATCH V2 net-next 0/8] Misc bug fixes & small enhancements for HNS3 Driver
From: Salil Mehta @ 2018-08-14 16:13 UTC (permalink / raw)
To: davem
Cc: salil.mehta, yisen.zhuang, lipeng321, mehta.salil.lnk, netdev,
linux-kernel, linuxarm
This patch-set presents some bug fixes and minor enhancements to
HNS3 Ethernet driver.
Rework Summary:
(*) Patch V1->V2
1. Fixed David S Miller's comments
2. Dropped patch 0005 "net: hns3: Fix for vf vlan delete failed problem" for now.
Fuyun Liang (1):
net: hns3: Fix for information of phydev lost problem when down/up
Jian Shen (1):
net: hns3: Fix for phy link issue when using marvell phy driver
Peng Li (2):
net: hns3: Add support for serdes loopback selftest
net: hns3: Add vlan filter setting by ethtool command -K
Xi Wang (1):
net: hns3: Fix for command format parsing error in
hclge_is_all_function_id_zero
Yunsheng Lin (3):
net: hns3: Fix desc num set to default when setting channel
net: hns3: Remove tx ring BD len register in hns3_enet
net: hns3: Set tx ring' tc info when netdev is up
drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 32 ++++++-
drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 2 +-
drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 11 ++-
.../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h | 12 +++
.../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 105 +++++++++++++++++----
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.c | 27 +++++-
.../ethernet/hisilicon/hns3/hns3pf/hclge_mdio.h | 4 +-
7 files changed, 165 insertions(+), 28 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-14 13:20 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <20180814121734.105769fa@redhat.com>
On 2018年08月14日 18:17, Jesper Dangaard Brouer wrote:
> On Tue, 14 Aug 2018 15:59:01 +0800
> Jason Wang <jasowang@redhat.com> wrote:
>
>> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
>>> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>>>> Hi:
>>>>
>>>> This series tries to implement XDP support for rx hanlder. This would
>>>> be useful for doing native XDP on stacked device like macvlan, bridge
>>>> or even bond.
>>>>
>>>> The idea is simple, let stacked device register a XDP rx handler. And
>>>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>>>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>>>> handler may then decide how to proceed, it could consume the buff, ask
>>>> driver to drop the packet or ask the driver to fallback to normal skb
>>>> path.
>>>>
>>>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>>>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>>>> example. For ease comparision, generic XDP support for rx handler was
>>>> also implemented.
>>>>
>>>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>>>> shows about 83% improvement.
>>> I'm missing the motiviation for this.
>>> It seems performance of such solution is ~1M packet per second.
>> Notice it was measured by virtio-net which is kind of slow.
>>
>>> What would be a real life use case for such feature ?
>> I had another run on top of 10G mlx4 and macvlan:
>>
>> XDP_DROP on mlx4: 14.0Mpps
>> XDP_DROP on macvlan: 10.05Mpps
>>
>> Perf shows macvlan_hash_lookup() and indirect call to
>> macvlan_handle_xdp() are the reasons for the number drop. I think the
>> numbers are acceptable. And we could try more optimizations on top.
>>
>> So here's real life use case is trying to have an fast XDP path for rx
>> handler based device:
>>
>> - For containers, we can run XDP for macvlan (~70% of wire speed). This
>> allows a container specific policy.
>> - For VM, we can implement macvtap XDP rx handler on top. This allow us
>> to forward packet to VM without building skb in the setup of macvtap.
>> - The idea could be used by other rx handler based device like bridge,
>> we may have a XDP fast forwarding path for bridge.
>>
>>> Another concern is that XDP users expect to get line rate performance
>>> and native XDP delivers it. 'generic XDP' is a fallback only
>>> mechanism to operate on NICs that don't have native XDP yet.
>> So I can replace generic XDP TX routine with a native one for macvlan.
> If you simply implement ndo_xdp_xmit() for macvlan, and instead use
> XDP_REDIRECT, then we are basically done.
As I replied in another thread this probably not true. Its
ndo_xdp_xmit() just need to call under layer device's ndo_xdp_xmit()
except for the case of bridge mode.
>
>
>>> Toshiaki's veth XDP work fits XDP philosophy and allows
>>> high speed networking to be done inside containers after veth.
>>> It's trying to get to line rate inside container.
>> This is one of the goal of this series as well. I agree veth XDP work
>> looks pretty fine, but it only work for a specific setup I believe since
>> it depends on XDP_REDIRECT which is supported by few drivers (and
>> there's no VF driver support).
> The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
> argument that only a few drivers implement this. Especially since all
> drivers also need to be extended with your proposed xdp_do_pass() call.
>
> (rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
> that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
> have to allocate HW TX-queue resources. If we disconnect RX and TX
> side of redirect, then we can implement RX-side in an afternoon.
That's exactly the point, ndo_xdp_xmit() may requires per CPU TX queues
which breaks assumptions of some drivers. And since we don't disconnect
RX and TX, it looks to me the partial implementation is even worse?
Consider a user can redirect from mlx4 to ixgbe but not ixgbe to mlx4.
>
>
>> And in order to make it work for a end
>> user, the XDP program still need logic like hash(map) lookup to
>> determine the destination veth.
> That _is_ the general idea behind XDP and eBPF, that we need to add logic
> that determine the destination. The kernel provides the basic
> mechanisms for moving/redirecting packets fast, and someone else
> builds an orchestration tool like Cilium, that adds the needed logic.
Yes, so my reply is for the concern about performance. I meant anyway
the hash lookup will make it not hit the wire speed.
>
> Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
> accessible from XDP.
Yes.
>
> For macvlan, I imagine that we could add a BPF helper that allows you
> to lookup/call macvlan_hash_lookup().
That's true but we still need a method to feed macvlan with XDP buff.
I'm not sure if this could be treated as another kind of redirection,
but ndo_xdp_xmit() could not be used for this case for sure. Compared to
redirection, XDP rx handler has its own advantages:
1) Use the exist API and userspace to setup the network topology instead
of inventing new tools and its own specific API. This means user can
just setup macvlan (macvtap, bridge or other) as usual and simply attach
XDP programs to both macvlan and its under layer device.
2) Ease the processing of complex logic, XDP can not do cloning or
reference counting. We can differ those cases and let normal networking
stack to deal with such packets seamlessly. I believe this is one of the
advantage of XDP. This makes us to focus on the fast path and greatly
simplify the codes.
Like ndo_xdp_xmit(), XDP rx handler is used to feed RX handler with XDP
buff. It's just another basic mechanism. Policy is still done by XDP
program itself.
Thanks
>
>
>>> This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
>>> and the users will get confused with forever slow modes of XDP.
>>>
>>> Please explain the problem you're trying to solve.
>>> "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
>>>
>
^ permalink raw reply
* Re: WARNING: suspicious RCU usage in bpf_prog_array_copy_core
From: Y Song @ 2018-08-14 15:59 UTC (permalink / raw)
To: syzbot; +Cc: Alexei Starovoitov, Daniel Borkmann, LKML, netdev, syzkaller-bugs
In-Reply-To: <000000000000863a6e057361feb4@google.com>
On Tue, Aug 14, 2018 at 2:40 AM, syzbot
<syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 4110b42356f3 Add linux-next specific files for 20180810
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=109bac02400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> dashboard link: https://syzkaller.appspot.com/bug?extid=6e72317008eef84a216b
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=157ef48a400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e16cf8400000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+6e72317008eef84a216b@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
>
> =============================
> WARNING: suspicious RCU usage
> 4.18.0-rc8-next-20180810+ #36 Not tainted
> -----------------------------
> kernel/bpf/core.c:1582 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 2, debug_locks = 1
> 2 locks held by syz-executor287/4449:
> #0: 00000000d8131c0c (&ctx->mutex){+.+.}, at:
> perf_event_ctx_lock_nested+0x375/0x600 kernel/events/core.c:1276
> #1: 000000006c916250 (bpf_event_mutex){+.+.}, at:
> perf_event_query_prog_array+0x1c6/0x380 kernel/trace/bpf_trace.c:1062
>
> stack backtrace:
> CPU: 1 PID: 4449 Comm: syz-executor287 Not tainted 4.18.0-rc8-next-20180810+
> #36
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> lockdep_rcu_suspicious+0x14a/0x153 kernel/locking/lockdep.c:4562
> bpf_prog_array_copy_core+0x2d9/0x360 kernel/bpf/core.c:1582
> bpf_prog_array_copy_info+0x9a/0x110 kernel/bpf/core.c:1720
> perf_event_query_prog_array+0x22e/0x380 kernel/trace/bpf_trace.c:1063
> _perf_ioctl+0x986/0x1600 kernel/events/core.c:5079
> perf_ioctl+0x59/0x80 kernel/events/core.c:5110
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:501 [inline]
> do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> __do_sys_ioctl fs/ioctl.c:709 [inline]
> __se_sys_ioctl fs/ioctl.c:707 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x440409
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fffc5fc1488 EFLAGS: 00000217 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440409
> RDX: 0000000020000180 RSI: 00000000c008240a RDI: 0000000000000003
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 00000000004002c8 R11: 0000000000000217 R12: 0000000000401c90
> R13: 0000000000401d20 R14: 0000000000000000
>
I will take a look at this one.
We have a mutex lock at kernel/trace/bpf_trace.c,
1062 mutex_lock(&bpf_event_mutex);
1063 ret = bpf_prog_array_copy_info(event->tp_event->prog_array,
1064 ids,
1065 ids_len,
1066 &prog_cnt);
1067 mutex_unlock(&bpf_event_mutex);
We may need a variant of rcu_dereference, e.g., rcu_dereference_protected.
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net: macb: Fix regression breaking non-MDIO fixed-link PHYs
From: Uwe Kleine-König @ 2018-08-14 15:58 UTC (permalink / raw)
To: Ahmad Fatoum
Cc: David S. Miller, Nicolas Ferre, netdev, mdf, stable, kernel,
Brad Mouring, Andrew Lunn, Florian Fainelli
In-Reply-To: <20180814141240.9085-1-a.fatoum@pengutronix.de>
Hello Ahmad,
On Tue, Aug 14, 2018 at 04:12:40PM +0200, Ahmad Fatoum wrote:
> The referenced commit broke initializing macb on the EVB-KSZ9477 eval board.
> There, of_mdiobus_register was called even for the fixed-link representing
> the SPI-connected switch PHY, with the result that the driver attempts to
> enumerate PHYs on a non-existent MDIO bus:
>
> libphy: MACB_mii_bus: probed
> mdio_bus f0028000.ethernet-ffffffff: fixed-link has invalid PHY address
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 0
> [snip]
> mdio_bus f0028000.ethernet-ffffffff: scan phy fixed-link at address 31
> macb f0028000.ethernet: broken fixed-link specification
>
> Cc: <stable@vger.kernel.org>
> Fixes: 739de9a1563a ("net: macb: Reorganize macb_mii bringup")
I added the people involved in 739de9a1563a to Cc. Maybe they want to
comment. So not stripping the remaining part of the original mail.
Best regards
Uwe
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 26 +++++++++++++++---------
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index a6c911bb5ce2..d202a03c42ed 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -481,11 +481,6 @@ static int macb_mii_probe(struct net_device *dev)
>
> if (np) {
> if (of_phy_is_fixed_link(np)) {
> - if (of_phy_register_fixed_link(np) < 0) {
> - dev_err(&bp->pdev->dev,
> - "broken fixed-link specification\n");
> - return -ENODEV;
> - }
> bp->phy_node = of_node_get(np);
> } else {
> bp->phy_node = of_parse_phandle(np, "phy-handle", 0);
> @@ -568,7 +563,7 @@ static int macb_mii_init(struct macb *bp)
> {
> struct macb_platform_data *pdata;
> struct device_node *np;
> - int err;
> + int err = -ENXIO;
>
> /* Enable management port */
> macb_writel(bp, NCR, MACB_BIT(MPE));
> @@ -591,10 +586,21 @@ static int macb_mii_init(struct macb *bp)
> dev_set_drvdata(&bp->dev->dev, bp->mii_bus);
>
> np = bp->pdev->dev.of_node;
> - if (pdata)
> - bp->mii_bus->phy_mask = pdata->phy_mask;
> + if (np && of_phy_is_fixed_link(np)) {
> + if (of_phy_register_fixed_link(np) < 0) {
> + dev_err(&bp->pdev->dev,
> + "broken fixed-link specification\n");
> + goto err_out_free_mdiobus;
> + }
> +
> + err = mdiobus_register(bp->mii_bus);
> + } else {
> + if (pdata)
> + bp->mii_bus->phy_mask = pdata->phy_mask;
> +
> + err = of_mdiobus_register(bp->mii_bus, np);
> + }
>
> - err = of_mdiobus_register(bp->mii_bus, np);
> if (err)
> goto err_out_free_mdiobus;
>
> @@ -606,9 +612,9 @@ static int macb_mii_init(struct macb *bp)
>
> err_out_unregister_bus:
> mdiobus_unregister(bp->mii_bus);
> +err_out_free_mdiobus:
> if (np && of_phy_is_fixed_link(np))
> of_phy_deregister_fixed_link(np);
> -err_out_free_mdiobus:
> of_node_put(bp->phy_node);
> mdiobus_free(bp->mii_bus);
> err_out:
> --
> 2.18.0
>
>
>
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH net-next v3] xen-netfront: fix warn message as irq device name has '/'
From: Xiao Liang @ 2018-08-14 15:21 UTC (permalink / raw)
To: netdev, xen-devel, davem, jgross, boris.ostrovsky
Cc: linux-kernel, Xiao Liang
There is a call trace generated after commit 2d408c0d4574b01b9ed45e02516888bf925e11a9(
xen-netfront: fix queue name setting). There is no 'device/vif/xx-q0-tx' file found
under /proc/irq/xx/.
This patch only picks up device type and id as its name.
With the patch, now /proc/interrupts looks like below and the warning message gone:
70: 21 0 0 0 xen-dyn -event vif0-q0-tx
71: 15 0 0 0 xen-dyn -event vif0-q0-rx
72: 14 0 0 0 xen-dyn -event vif0-q1-tx
73: 33 0 0 0 xen-dyn -event vif0-q1-rx
74: 12 0 0 0 xen-dyn -event vif0-q2-tx
75: 24 0 0 0 xen-dyn -event vif0-q2-rx
76: 19 0 0 0 xen-dyn -event vif0-q3-tx
77: 21 0 0 0 xen-dyn -event vif0-q3-rx
Below is call trace information without this patch:
name 'device/vif/0-q0-tx'
WARNING: CPU: 2 PID: 37 at fs/proc/generic.c:174 __xlate_proc_name+0x85/0xa0
RIP: 0010:__xlate_proc_name+0x85/0xa0
RSP: 0018:ffffb85c40473c18 EFLAGS: 00010286
RAX: 0000000000000000 RBX: 0000000000000006 RCX: 0000000000000006
RDX: 0000000000000007 RSI: 0000000000000096 RDI: ffff984c7f516930
RBP: ffffb85c40473cb8 R08: 000000000000002c R09: 0000000000000229
R10: 0000000000000000 R11: 0000000000000001 R12: ffffb85c40473c98
R13: ffffb85c40473cb8 R14: ffffb85c40473c50 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff984c7f500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f69b6899038 CR3: 000000001c20a006 CR4: 00000000001606e0
Call Trace:
__proc_create+0x45/0x230
? snprintf+0x49/0x60
proc_mkdir_data+0x35/0x90
register_handler_proc+0xef/0x110
? proc_register+0xfc/0x110
? proc_create_data+0x70/0xb0
__setup_irq+0x39b/0x660
? request_threaded_irq+0xad/0x160
request_threaded_irq+0xf5/0x160
? xennet_tx_buf_gc+0x1d0/0x1d0 [xen_netfront]
bind_evtchn_to_irqhandler+0x3d/0x70
? xenbus_alloc_evtchn+0x41/0xa0
netback_changed+0xa46/0xcda [xen_netfront]
? find_watch+0x40/0x40
xenwatch_thread+0xc5/0x160
? finish_wait+0x80/0x80
kthread+0x112/0x130
? kthread_create_worker_on_cpu+0x70/0x70
ret_from_fork+0x35/0x40
Code: 81 5c 00 48 85 c0 75 cc 5b 49 89 2e 31 c0 5d 4d 89 3c 24 41 5c 41 5d 41 5e 41 5f c3 4c 89 ee 48 c7 c7 40 4f 0e b4 e8 65 ea d8 ff <0f> 0b b8 fe ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 0f 1f
---[ end trace 650e5561b0caab3a ]---
Signed-off-by: Xiao Liang <xiliang@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
---
drivers/net/xen-netfront.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 799cba4624a5..c4955bd303bb 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1604,14 +1604,16 @@ static int xennet_init_queue(struct netfront_queue *queue)
{
unsigned short i;
int err = 0;
+ char *devid;
spin_lock_init(&queue->tx_lock);
spin_lock_init(&queue->rx_lock);
timer_setup(&queue->rx_refill_timer, rx_refill_timeout, 0);
- snprintf(queue->name, sizeof(queue->name), "%s-q%u",
- queue->info->xbdev->nodename, queue->id);
+ devid = strrchr(queue->info->xbdev->nodename, '/') + 1;
+ snprintf(queue->name, sizeof(queue->name), "vif%s-q%u",
+ devid, queue->id);
/* Initialise tx_skbs as a free chain containing every entry. */
queue->tx_skb_freelist = 0;
--
2.17.1
^ permalink raw reply related
* [iproute PATCH 3/3] testsuite: Add a first ss test validating ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
This tests a few ssfilter expressions by selecting sockets from a TCP
dump file. The dump was created using the following command:
| ss -ntaD testsuite/tests/ss/ss1.dump
It is fed into ss via TCPDIAG_FILE environment variable.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/tests/ss/ss1.dump | Bin 0 -> 720 bytes
testsuite/tests/ss/ssfilter.t | 48 ++++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+)
create mode 100644 testsuite/tests/ss/ss1.dump
create mode 100755 testsuite/tests/ss/ssfilter.t
diff --git a/testsuite/tests/ss/ss1.dump b/testsuite/tests/ss/ss1.dump
new file mode 100644
index 0000000000000000000000000000000000000000..9c273231c78418593cabda324ca20d5a6d41e1aa
GIT binary patch
literal 720
zcmYdbU|<koU}A81#K^!c$-uzG1r!hiVj=)DnwkbEe>Nin11kdun3n(~QOsv#0-E2u
z3TO>b6#}61K{9Mm>1mU45ek8<2e$al?_I?phHf4@A7mgq)YMKS^Irfxb<qmH`3z!5
zI?&An@_`;h1*}l+IW<)G-$HV~2v7|(Quu?kWB@U8m~jCOCpJ!4Kn5Uz1}J+jQk<|d
zaDxLs0Vs!J4=`@#c`%6mJHX%s)dr$e(D>kZgGJtnxD>cjP}t=IBMn#FbAjW2%?&j3
Wu$m7G%#dh=`5=oj%@O8f3p)VpCN7Tv
literal 0
HcmV?d00001
diff --git a/testsuite/tests/ss/ssfilter.t b/testsuite/tests/ss/ssfilter.t
new file mode 100755
index 0000000000000..e74f1765cb723
--- /dev/null
+++ b/testsuite/tests/ss/ssfilter.t
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+. lib/generic.sh
+
+# % ./misc/ss -Htna
+# LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
+# ESTAB 0 0 10.0.0.1:22 10.0.0.1:36266
+# ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22
+# ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312
+export TCPDIAG_FILE="$(dirname $0)/ss1.dump"
+
+ts_log "[Testing ssfilter]"
+
+ts_ss "$0" "Match dport = 22" -Htna dport = 22
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match dport 22" -Htna dport 22
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match (dport)" -Htna '( dport = 22 )'
+test_on "ESTAB 0 0 10.0.0.1:36266 10.0.0.1:22"
+
+ts_ss "$0" "Match src = 0.0.0.0" -Htna src = 0.0.0.0
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src 0.0.0.0" -Htna src 0.0.0.0
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src sport" -Htna src 0.0.0.0 sport = 22
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src and sport" -Htna src 0.0.0.0 and sport = 22
+test_on "LISTEN 0 128 0.0.0.0:22 0.0.0.0:*"
+
+ts_ss "$0" "Match src and sport and dport" -Htna src 10.0.0.1 and sport = 22 and dport = 50312
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match src and sport and (dport)" -Htna 'src 10.0.0.1 and sport = 22 and ( dport = 50312 )'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match src and (sport and dport)" -Htna 'src 10.0.0.1 and ( sport = 22 and dport = 50312 )'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match (src and sport) and dport" -Htna '( src 10.0.0.1 and sport = 22 ) and dport = 50312'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
+
+ts_ss "$0" "Match (src or src) and dst" -Htna '( src 0.0.0.0 or src 10.0.0.1 ) and dst 10.0.0.2'
+test_on "ESTAB 0 0 10.0.0.1:22 10.0.0.2:50312"
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 0/3] Fix and test ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
This series contains a fix for ssfilter and introduces a testscript to
verify correct functionality.
Phil Sutter (3):
ss: Review ssfilter
testsuite: Prepare for ss tests
testsuite: Add a first ss test validating ssfilter
misc/ssfilter.y | 36 ++++++++++++++-----------
testsuite/Makefile | 2 +-
testsuite/lib/generic.sh | 37 ++++++++++----------------
testsuite/tests/ss/ss1.dump | Bin 0 -> 720 bytes
testsuite/tests/ss/ssfilter.t | 48 ++++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 39 deletions(-)
create mode 100644 testsuite/tests/ss/ss1.dump
create mode 100755 testsuite/tests/ss/ssfilter.t
--
2.18.0
^ permalink raw reply
* [iproute PATCH 1/3] ss: Review ssfilter
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
The original problem was ssfilter rejecting single expressions if
enclosed in braces, such as:
| sport = 22 or ( dport = 22 )
This is fixed by allowing 'expr' to be an 'exprlist' enclosed in braces.
The no longer required recursion in 'exprlist' being an 'exprlist'
enclosed in braces is dropped.
In addition to that, a few other things are changed:
* Remove pointless 'null' prefix in 'appled' before 'exprlist'.
* For simple equals matches, '=' operator was required for ports but not
allowed for hosts. Make this consistent by making '=' operator
optional in both cases.
Reported-by: Samuel Mannehed <samuel@cendio.se>
Fixes: b2038cc0b2403 ("ssfilter: Eliminate shift/reduce conflicts")
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
misc/ssfilter.y | 36 +++++++++++++++++++++---------------
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/misc/ssfilter.y b/misc/ssfilter.y
index 88d4229a9b241..0413dddaa7584 100644
--- a/misc/ssfilter.y
+++ b/misc/ssfilter.y
@@ -42,24 +42,22 @@ static void yyerror(char *s)
%nonassoc '!'
%%
-applet: null exprlist
+applet: exprlist
{
- *yy_ret = $2;
- $$ = $2;
+ *yy_ret = $1;
+ $$ = $1;
}
| null
;
+
null: /* NOTHING */ { $$ = NULL; }
;
+
exprlist: expr
| '!' expr
{
$$ = alloc_node(SSF_NOT, $2);
}
- | '(' exprlist ')'
- {
- $$ = $2;
- }
| exprlist '|' expr
{
$$ = alloc_node(SSF_OR, $1);
@@ -77,13 +75,21 @@ exprlist: expr
}
;
-expr: DCOND HOSTCOND
+eq: '='
+ | /* nothing */
+ ;
+
+expr: '(' exprlist ')'
+ {
+ $$ = $2;
+ }
+ | DCOND eq HOSTCOND
{
- $$ = alloc_node(SSF_DCOND, $2);
+ $$ = alloc_node(SSF_DCOND, $3);
}
- | SCOND HOSTCOND
+ | SCOND eq HOSTCOND
{
- $$ = alloc_node(SSF_SCOND, $2);
+ $$ = alloc_node(SSF_SCOND, $3);
}
| DPORT GEQ HOSTCOND
{
@@ -101,7 +107,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_D_GE, $3));
}
- | DPORT '=' HOSTCOND
+ | DPORT eq HOSTCOND
{
$$ = alloc_node(SSF_DCOND, $3);
}
@@ -126,7 +132,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_S_GE, $3));
}
- | SPORT '=' HOSTCOND
+ | SPORT eq HOSTCOND
{
$$ = alloc_node(SSF_SCOND, $3);
}
@@ -134,7 +140,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_SCOND, $3));
}
- | DEVNAME '=' DEVCOND
+ | DEVNAME eq DEVCOND
{
$$ = alloc_node(SSF_DEVCOND, $3);
}
@@ -142,7 +148,7 @@ expr: DCOND HOSTCOND
{
$$ = alloc_node(SSF_NOT, alloc_node(SSF_DEVCOND, $3));
}
- | FWMARK '=' MARKMASK
+ | FWMARK eq MARKMASK
{
$$ = alloc_node(SSF_MARKMASK, $3);
}
--
2.18.0
^ permalink raw reply related
* [iproute PATCH 2/3] testsuite: Prepare for ss tests
From: Phil Sutter @ 2018-08-14 12:18 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Samuel Mannehed
In-Reply-To: <20180814121808.24774-1-phil@nwl.cc>
This merges the shared bits from ts_tc() and ts_ip() into a common
function for being wrapped by the first ones and adds a third ts_ss()
for testing ss commands.
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
testsuite/Makefile | 2 +-
testsuite/lib/generic.sh | 37 ++++++++++++++-----------------------
2 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/testsuite/Makefile b/testsuite/Makefile
index 2a54e5c845e65..8fcbc557ff9a7 100644
--- a/testsuite/Makefile
+++ b/testsuite/Makefile
@@ -65,7 +65,7 @@ endif
TMP_ERR=`mktemp /tmp/tc_testsuite.XXXXXX`; \
TMP_OUT=`mktemp /tmp/tc_testsuite.XXXXXX`; \
STD_ERR="$$TMP_ERR" STD_OUT="$$TMP_OUT" \
- TC="$$i/tc/tc" IP="$$i/ip/ip" DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
+ TC="$$i/tc/tc" IP="$$i/ip/ip" SS=$$i/misc/ss DEV="$(DEV)" IPVER="$@" SNAME="$$i" \
ERRF="$(RESULTS_DIR)/$@.$$o.err" $(KENV) $(PREFIX) tests/$@ > $(RESULTS_DIR)/$@.$$o.out; \
if [ "$$?" = "127" ]; then \
echo "SKIPPED"; \
diff --git a/testsuite/lib/generic.sh b/testsuite/lib/generic.sh
index 8cef20fa1b280..f92260fc40cf3 100644
--- a/testsuite/lib/generic.sh
+++ b/testsuite/lib/generic.sh
@@ -26,16 +26,17 @@ ts_skip()
exit 127
}
-ts_tc()
+__ts_cmd()
{
+ CMD=$1; shift
SCRIPT=$1; shift
DESC=$1; shift
- $TC $@ 2> $STD_ERR > $STD_OUT
+ $CMD $@ 2> $STD_ERR > $STD_OUT
if [ -s $STD_ERR ]; then
ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $TC $@"
+ ts_err "command: $CMD $@"
ts_err "stderr output:"
ts_err_cat $STD_ERR
if [ -s $STD_OUT ]; then
@@ -50,29 +51,19 @@ ts_tc()
fi
}
-ts_ip()
+ts_tc()
{
- SCRIPT=$1; shift
- DESC=$1; shift
+ __ts_cmd "$TC" "$@"
+}
- $IP $@ 2> $STD_ERR > $STD_OUT
- RET=$?
+ts_ip()
+{
+ __ts_cmd "$IP" "$@"
+}
- if [ -s $STD_ERR ] || [ "$RET" != "0" ]; then
- ts_err "${SCRIPT}: ${DESC} failed:"
- ts_err "command: $IP $@"
- ts_err "stderr output:"
- ts_err_cat $STD_ERR
- if [ -s $STD_OUT ]; then
- ts_err "stdout output:"
- ts_err_cat $STD_OUT
- fi
- elif [ -s $STD_OUT ]; then
- echo "${SCRIPT}: ${DESC} succeeded with output:"
- cat $STD_OUT
- else
- echo "${SCRIPT}: ${DESC} succeeded"
- fi
+ts_ss()
+{
+ __ts_cmd "$SS" "$@"
}
ts_qdisc_available()
--
2.18.0
^ permalink raw reply related
* Re: [PATCH bpf] Revert "xdp: add NULL pointer check in __xdp_return()"
From: Björn Töpel @ 2018-08-14 12:02 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Alexei Starovoitov, Netdev, Taehee Yoo,
Jesper Dangaard Brouer, Björn Töpel, Karlsson, Magnus,
Magnus Karlsson, kafai
In-Reply-To: <20180810092625.1ad1cce4@cakuba.netronome.com>
Den fre 10 aug. 2018 kl 18:26 skrev Jakub Kicinski
<jakub.kicinski@netronome.com>:
>
> On Fri, 10 Aug 2018 17:16:45 +0200, Björn Töpel wrote:
> > Den fre 10 aug. 2018 kl 16:10 skrev Daniel Borkmann <daniel@iogearbox.net>:
> > >
> > > On 08/10/2018 11:28 AM, Björn Töpel wrote:
> > > > From: Björn Töpel <bjorn.topel@intel.com>
> > > >
> > > > This reverts commit 36e0f12bbfd3016f495904b35e41c5711707509f.
> > > >
> > > > The reverted commit adds a WARN to check against NULL entries in the
> > > > mem_id_ht rhashtable. Any kernel path implementing the XDP (generic or
> > > > driver) fast path is required to make a paired
> > > > xdp_rxq_info_reg/xdp_rxq_info_unreg call for proper function. In
> > > > addition, a driver using a different allocation scheme than the
> > > > default MEM_TYPE_PAGE_SHARED is required to additionally call
> > > > xdp_rxq_info_reg_mem_model.
> > > >
> > > > For MEM_TYPE_ZERO_COPY, an xdp_rxq_info_reg_mem_model call ensures
> > > > that the mem_id_ht rhashtable has a properly inserted allocator id. If
> > > > not, this would be a driver bug. A NULL pointer kernel OOPS is
> > > > preferred to the WARN.
> > > >
> > > > Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com>
> > > > Signed-off-by: Björn Töpel <bjorn.topel@intel.com>
> > >
> > > Given the last bpf pr went out yesterday night, I've applied this to
> > > bpf-next (worst case we can just route it via stable), thanks!
> >
> > Ah, right! Thanks!
> >
> > bpf-next is OK. (Since this path is currently not used yet by any driver... :-()
>
> Wasn't this dead code, anyway? The frame return path is for redirects,
> and one can't convert_to_xdp_frame presently?
Indeed, dead it is. Hmm, I'll remove it as part of the i40e zc submission.
Björn
^ permalink raw reply
* Re: [Query]: DSA Understanding
From: Lad, Prabhakar @ 2018-08-14 11:49 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, netdev
In-Reply-To: <4ab52cf7-e340-ff0b-4352-f18dcb9e0e6b@gmail.com>
Hi Florian,
On Mon, Aug 13, 2018 at 7:57 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> On 08/13/2018 08:58 AM, Lad, Prabhakar wrote:
> > Hi Andrew/Florain,
> >
> > On Mon, Aug 13, 2018 at 2:38 PM Andrew Lunn <andrew@lunn.ch> wrote:
> >>
> >>>> I agree, this should be padding packets correctly, can you still
> >>>> instrument cpsw to make sure that what comes to its ndo_start_xmit() is
> >>>> ETH_ZLEN + tag_len or more?
> >>>>
> >>> Yes I can confirm the skb->len is always >= 62 (ETH_ZLEN + 2)
> >>
> >> Which switch are you using?
> >>
> >> Marvell switches use either 4 or 8 bytes of tag. Broadcom has 4, KSZ
> >> has 1 for packets going to the switch, lan9303 has 4, mtd uses 4, qca
> >> has 2.
> >>
> > I am using the KSZ switch. for Ingress it has 1 byte and for Egress it
> > has 2 bytes.
> > I came across patch [1] and padded 2 more bytes in ksz_xmit() and I was
> > successfully able to ping from lan4 to PC. Thank you very much for
> > your guidance/support.
> >
> > Now I have stumbled into a different issue:
> >
> > Case 1 Works:
> > =================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > For the above ping works from both directions.
> >
> > CASE 2 Doesn’t Work:
> > =========================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > lan4 = 192.168.0.4
> > PC2 = 192.168.0.11
> >
> > Ping from lan0 to PC1 and PC1 to lan0 works
> > But ping from PC2 to lan4 and lan4 to PC2 fails.
> >
> > CASE 3 Works:
> > =========================
> > lan0 = 192.168.0.1
> > PC1 = 192.168.0.10
> > lan4 = 192.168.4.4
> > PC2 = 192.168.4.11
> >
> > With the above setup ping works.
> >
> > [Query] Why does ping fail in case 2. Any thoughts what I am missing here ?
> > or is it the expected behaviour ?
>
> For case 2, what I suspect is happening is that the machine that has
> lan1/lan4, because you have put lan1/lan4 in the same subnet, does not
> know how to respond to PC2 because it is unable to select an appropriate
> output interface. In such cases, you might have to add an explicit /32
> route that forces telling the kernel that PC2 is accessible via lan2.
>
That did the trick thank you, following is my setup
lan0 = 192.168.0.1
PC1 = 192.168.0.10
lan4 = 192.168.0.4
PC2 = 192.168.0.11
route add 192.168.0.11 gw 192.168.0.4
route add 192.168.0.10 gw 192.168.0.1
And now ping works either ways. Is this setup for adding the route a valid way
to do it ? Or is there some standard way I need to follow which I am missing.
> Andrew, do you see an other explanation for that?
>
> >
> > [1] https://lore.kernel.org/patchwork/patch/851457/
>
> This patch works, but I think it is still working by "accident" in that
> if you have both VLAN tags + KSZ tag, you would likely still be too
> short by a few bytes.
>
too take care of this now I making sure the skb->len is padded to VLAN_ETH_ZLEN
in tag_ksz.c ksz_xmit() function.
Cheers,
--Prabhakar Lad
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: David Ahern @ 2018-08-14 14:03 UTC (permalink / raw)
To: Jason Wang, Jesper Dangaard Brouer
Cc: Alexei Starovoitov, netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <03ab3b18-9b13-8169-7e68-ada307694bc1@redhat.com>
On 8/14/18 7:20 AM, Jason Wang wrote:
>
>
> On 2018年08月14日 18:17, Jesper Dangaard Brouer wrote:
>> On Tue, 14 Aug 2018 15:59:01 +0800
>> Jason Wang <jasowang@redhat.com> wrote:
>>
>>> On 2018年08月14日 08:32, Alexei Starovoitov wrote:
>>>> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>>>>> Hi:
>>>>>
>>>>> This series tries to implement XDP support for rx hanlder. This would
>>>>> be useful for doing native XDP on stacked device like macvlan, bridge
>>>>> or even bond.
>>>>>
>>>>> The idea is simple, let stacked device register a XDP rx handler. And
>>>>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>>>>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>>>>> handler may then decide how to proceed, it could consume the buff, ask
>>>>> driver to drop the packet or ask the driver to fallback to normal skb
>>>>> path.
>>>>>
>>>>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>>>>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>>>>> example. For ease comparision, generic XDP support for rx handler was
>>>>> also implemented.
>>>>>
>>>>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>>>>> shows about 83% improvement.
>>>> I'm missing the motiviation for this.
>>>> It seems performance of such solution is ~1M packet per second.
>>> Notice it was measured by virtio-net which is kind of slow.
>>>
>>>> What would be a real life use case for such feature ?
>>> I had another run on top of 10G mlx4 and macvlan:
>>>
>>> XDP_DROP on mlx4: 14.0Mpps
>>> XDP_DROP on macvlan: 10.05Mpps
>>>
>>> Perf shows macvlan_hash_lookup() and indirect call to
>>> macvlan_handle_xdp() are the reasons for the number drop. I think the
>>> numbers are acceptable. And we could try more optimizations on top.
>>>
>>> So here's real life use case is trying to have an fast XDP path for rx
>>> handler based device:
>>>
>>> - For containers, we can run XDP for macvlan (~70% of wire speed). This
>>> allows a container specific policy.
>>> - For VM, we can implement macvtap XDP rx handler on top. This allow us
>>> to forward packet to VM without building skb in the setup of macvtap.
>>> - The idea could be used by other rx handler based device like bridge,
>>> we may have a XDP fast forwarding path for bridge.
>>>
>>>> Another concern is that XDP users expect to get line rate performance
>>>> and native XDP delivers it. 'generic XDP' is a fallback only
>>>> mechanism to operate on NICs that don't have native XDP yet.
>>> So I can replace generic XDP TX routine with a native one for macvlan.
>> If you simply implement ndo_xdp_xmit() for macvlan, and instead use
>> XDP_REDIRECT, then we are basically done.
>
> As I replied in another thread this probably not true. Its
> ndo_xdp_xmit() just need to call under layer device's ndo_xdp_xmit()
> except for the case of bridge mode.
>
>>
>>
>>>> Toshiaki's veth XDP work fits XDP philosophy and allows
>>>> high speed networking to be done inside containers after veth.
>>>> It's trying to get to line rate inside container.
>>> This is one of the goal of this series as well. I agree veth XDP work
>>> looks pretty fine, but it only work for a specific setup I believe since
>>> it depends on XDP_REDIRECT which is supported by few drivers (and
>>> there's no VF driver support).
>> The XDP_REDIRECT (RX-side) is trivial to add to drivers. It is a bad
>> argument that only a few drivers implement this. Especially since all
>> drivers also need to be extended with your proposed xdp_do_pass() call.
>>
>> (rant) The thing that is delaying XDP_REDIRECT adaption in drivers, is
>> that it is harder to implement the TX-side, as the ndo_xdp_xmit() call
>> have to allocate HW TX-queue resources. If we disconnect RX and TX
>> side of redirect, then we can implement RX-side in an afternoon.
>
> That's exactly the point, ndo_xdp_xmit() may requires per CPU TX queues
> which breaks assumptions of some drivers. And since we don't disconnect
> RX and TX, it looks to me the partial implementation is even worse?
> Consider a user can redirect from mlx4 to ixgbe but not ixgbe to mlx4.
>
>>
>>
>>> And in order to make it work for a end
>>> user, the XDP program still need logic like hash(map) lookup to
>>> determine the destination veth.
>> That _is_ the general idea behind XDP and eBPF, that we need to add logic
>> that determine the destination. The kernel provides the basic
>> mechanisms for moving/redirecting packets fast, and someone else
>> builds an orchestration tool like Cilium, that adds the needed logic.
>
> Yes, so my reply is for the concern about performance. I meant anyway
> the hash lookup will make it not hit the wire speed.
>
>>
>> Did you notice that we (Ahern) added bpf_fib_lookup a FIB route lookup
>> accessible from XDP.
>
> Yes.
>
>>
>> For macvlan, I imagine that we could add a BPF helper that allows you
>> to lookup/call macvlan_hash_lookup().
>
> That's true but we still need a method to feed macvlan with XDP buff.
> I'm not sure if this could be treated as another kind of redirection,
> but ndo_xdp_xmit() could not be used for this case for sure. Compared to
> redirection, XDP rx handler has its own advantages:
>
> 1) Use the exist API and userspace to setup the network topology instead
> of inventing new tools and its own specific API. This means user can
> just setup macvlan (macvtap, bridge or other) as usual and simply attach
> XDP programs to both macvlan and its under layer device.
> 2) Ease the processing of complex logic, XDP can not do cloning or
> reference counting. We can differ those cases and let normal networking
> stack to deal with such packets seamlessly. I believe this is one of the
> advantage of XDP. This makes us to focus on the fast path and greatly
> simplify the codes.
>
> Like ndo_xdp_xmit(), XDP rx handler is used to feed RX handler with XDP
> buff. It's just another basic mechanism. Policy is still done by XDP
> program itself.
>
I have been looking into handling stacked devices via lookup helper
functions. The idea is that a program only needs to be installed on the
root netdev (ie., the one representing the physical port), and it can
use helpers to create an efficient pipeline to decide what to do with
the packet in the presence of stacked devices.
For example, anyone doing pure L3 could do:
{port, vlan} --> [ find l2dev ] --> [ find l3dev ] ...
--> [ l3 forward lookup ] --> [ header rewrite ] --> XDP_REDIRECT
port is the netdev associated with the ingress_ifindex in the xdp_md
context, vlan is the vlan in the packet or the assigned PVID if
relevant. From there l2dev could be a bond or bridge device for example,
and l3dev is the one with a network address (vlan netdev, bond netdev, etc).
I have L3 forwarding working for vlan devices and bonds. I had not
considered macvlans specifically yet, but it should be straightforward
to add.
^ permalink raw reply
* Re: PROBLEM: Using BPF_PROG_TEST_RUN with data_out != NULL is unsafe
From: Lorenz Bauer @ 2018-08-14 10:59 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: ast, netdev, linux-kernel
In-Reply-To: <c3907b6a-a7cd-0fda-27fd-9357cf63cfec@iogearbox.net>
Sorry for the late reply.
On 4 April 2018 at 11:01, Daniel Borkmann <daniel@iogearbox.net> wrote:
> In case you point data_in and data_out to the same address, then the total buffer size therefore has to be
> attr.test.data_size_in + 256 in order to not overrun anything while not being
> aware of the BPF test program. The XDP_PACKET_HEADROOM is exposed to user space
> in linux/bpf.h.
Would it be possible to extend the API of BPF_PROG_TEST_RUN to allow
user space to specify the
length of the output buffer? The kernel could then either clamp
output, or return an error.
The current API seems fundamentally hard to use, and unsafe. It leads
to kludges like [1] in a library
I'm maintaining.
1: https://github.com/newtools/ebpf/blob/f4398602ca2a37b99a1f29df9a7e8adcc57be680/prog.go#L200-L204
--
Lorenz Bauer | Systems Engineer
25 Lavington St., London SE1 0NZ
www.cloudflare.com
^ permalink raw reply
* Re: [PATCH net 2/2] net/mlx5e: Cleanup of dcbnl related fields
From: Håkon Bugge @ 2018-08-14 10:52 UTC (permalink / raw)
To: Yuval Shaia; +Cc: Saeed Mahameed, David S. Miller, netdev, Huy Nguyen
In-Reply-To: <20180814090151.GA3787@lap1>
> On 14 Aug 2018, at 11:01, Yuval Shaia <yuval.shaia@oracle.com> wrote:
>
> On Wed, Aug 08, 2018 at 03:48:08PM -0700, Saeed Mahameed wrote:
>> From: Huy Nguyen <huyn@mellanox.com>
>>
>> Remove unused netdev_registered_init/remove in en.h
>> Return ENOSUPPORT if the check MLX5_DSCP_SUPPORTED fails.
>
> s/ENOSUPPORT/EOPNOTSUPP
> (noted by Haakon)
Sure did,
>
>> Remove extra white space
and I also said that this has nothing to with the commit (no matter how tempting it can be) ;-)
Thxs, Håkon
>>
>> Fixes: 2a5e7a1344f4 ("net/mlx5e: Add dcbnl dscp to priority support")
>> Signed-off-by: Huy Nguyen <huyn@mellanox.com>
>> Cc: Yuval Shaia <yuval.shaia@oracle.com>
>> Reviewed-by: Parav Pandit <parav@mellanox.com>
>> Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
>> ---
>> drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 --
>> .../ethernet/mellanox/mlx5/core/en_dcbnl.c | 30 +++++++------------
>> 2 files changed, 11 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> index eb9eb7aa953a..405236cf0b04 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
>> @@ -858,8 +858,6 @@ struct mlx5e_profile {
>> mlx5e_fp_handle_rx_cqe handle_rx_cqe;
>> mlx5e_fp_handle_rx_cqe handle_rx_cqe_mpwqe;
>> } rx_handlers;
>> - void (*netdev_registered_init)(struct mlx5e_priv *priv);
>> - void (*netdev_registered_remove)(struct mlx5e_priv *priv);
>> int max_tc;
>> };
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> index e33afa8d2417..722998d68564 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>> @@ -443,16 +443,12 @@ static int mlx5e_dcbnl_ieee_setapp(struct net_device *dev, struct dcb_app *app)
>> bool is_new;
>> int err;
>>
>> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
>> - return -EINVAL;
>> -
>> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
>> - return -EINVAL;
>> -
>> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
>> - return -EINVAL;
>> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
>> + !MLX5_DSCP_SUPPORTED(priv->mdev))
>> + return -EOPNOTSUPP;
>>
>> - if (app->protocol >= MLX5E_MAX_DSCP)
>> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
>> + (app->protocol >= MLX5E_MAX_DSCP))
>> return -EINVAL;
>>
>> /* Save the old entry info */
>> @@ -500,16 +496,12 @@ static int mlx5e_dcbnl_ieee_delapp(struct net_device *dev, struct dcb_app *app)
>> struct mlx5e_priv *priv = netdev_priv(dev);
>> int err;
>>
>> - if (app->selector != IEEE_8021QAZ_APP_SEL_DSCP)
>> - return -EINVAL;
>> -
>> - if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager))
>> - return -EINVAL;
>> -
>> - if (!MLX5_DSCP_SUPPORTED(priv->mdev))
>> - return -EINVAL;
>> + if (!MLX5_CAP_GEN(priv->mdev, vport_group_manager) ||
>> + !MLX5_DSCP_SUPPORTED(priv->mdev))
>> + return -EOPNOTSUPP;
>>
>> - if (app->protocol >= MLX5E_MAX_DSCP)
>> + if ((app->selector != IEEE_8021QAZ_APP_SEL_DSCP) ||
>> + (app->protocol >= MLX5E_MAX_DSCP))
>> return -EINVAL;
>>
>> /* Skip if no dscp app entry */
>> @@ -1146,7 +1138,7 @@ static int mlx5e_set_trust_state(struct mlx5e_priv *priv, u8 trust_state)
>> {
>> int err;
>>
>> - err = mlx5_set_trust_state(priv->mdev, trust_state);
>> + err = mlx5_set_trust_state(priv->mdev, trust_state);
>> if (err)
>> return err;
>> priv->dcbx_dp.trust_state = trust_state;
>> --
>> 2.17.0
>>
^ permalink raw reply
* [PATCH net] cxgb4: Add new T5 PCI device ids 0x50af and 0x50b0
From: Ganesh Goudar @ 2018-08-14 10:51 UTC (permalink / raw)
To: netdev, davem; +Cc: dt, Ganesh Goudar
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index e3adf43..60df66f 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -189,6 +189,8 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x50ac), /* Custom T540-BT */
CH_PCI_ID_TABLE_FENTRY(0x50ad), /* Custom T520-CR */
CH_PCI_ID_TABLE_FENTRY(0x50ae), /* Custom T540-XL-SO */
+ CH_PCI_ID_TABLE_FENTRY(0x50af), /* Custom T580-KR-SO */
+ CH_PCI_ID_TABLE_FENTRY(0x50b0), /* Custom T520-CR-LOM */
/* T6 adapters:
*/
--
2.1.0
^ permalink raw reply related
* Re: linux-next: build warning after merge of the net-next tree
From: Guenter Roeck @ 2018-08-14 13:28 UTC (permalink / raw)
To: Masahiro Yamada
Cc: Stephen Rothwell, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Lunn
In-Reply-To: <CAK7LNAQgdqpi60eH-Sfnr+U9DKpwCL=wPdhJA6=hpv3cicVotw@mail.gmail.com>
On 08/14/2018 12:05 AM, Masahiro Yamada wrote:
> 2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
>>> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>>>> Hi Guenter,
>>>>
>>>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>
>>>>> On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>>>>>>
>>>>>> On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>
>>>>>>> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>>>> allmodconfig) produced this warning:
>>>>>>>>
>>>>>>>> *
>>>>>>>> * Restart config...
>>>>>>>> *
>>>>>>>> ....
>>>>>>>>
>>>>>>>> This is output by my "make allmodconfig" and only started after merging
>>>>>>>> the net-next tree today. It has continued for further merges/builds.
>>>>>>>>
>>>>>>>> I suspect commit
>>>>>>>>
>>>>>>>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>>>>>>>
>>>>>>>> which added an "imply" clause.
>>>>>>>>
>>>>>>> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>>>>>>> not. Is that a caveat when using "imply", and does it mean that "imply"
>>>>>>> should better not be used ?
>>>>>>
>>>>>> I don't know, sorry. It was just my best guess from what I could see
>>>>>> had changed.
>>>>>>
>>>>>> I wonder if it makes a difference that I am doing my "make
>>>>>> allmodconfig" on top of a previous "make allmodconfig" and some symbols
>>>>>> are marked as "NEW" (though they are not symbols related to the changes
>>>>>> that happened during the net-next tree merge)?
>>>>>>
>>>>>
>>>>> I tried to reproduce the problem, but I don't see the message.
>>>>>
>>>>> What I do see, though, is that "make allmodconfig" on a clean tree,
>>>>> followed by "make menuconfig", results in configuration changes.
>>>>> Specifically,
>>>>>
>>>>> > CONFIG_ARC_EMAC_CORE=m
>>>>> > CONFIG_ARC_EMAC=m
>>>>> > CONFIG_EMAC_ROCKCHIP=m
>>>>>
>>>>> is removed by menuconfig, and a large number of "# ... is not set"
>>>>> configuration lines are added. Weird and bad, since several of the
>>>>> disabled configurations _should_ be enabled by "make allmodconfig",
>>>>> and a large number of hwmon drivers are affected. Bisect does point
>>>>> to "net: phy: sfp: Add HWMON support for module sensors", meaning
>>>>> "imply hwmon" does have severe side effects and can not be used.
>>>>>
>>>>> I'll try to find a fix.
>>>>
>>>> OK, my mistake, the "make allmodconfig" works, the following "make"
>>>> causes the config restart. (I am actually doing cross builds and using
>>>> an external object directory, in case that matters.)
>>>>
>>>> I removed the "imply HWMON" line added by the above commit and the
>>>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>>>> of the imply fixes it.
>>>
>>> Yes, replacing imply with the dependency is what I did in the fixup patch.
>>> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>>>
>>> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
>>> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
>>> imply doesn't work, but I think I'll stay away from it in the future.
>>>
>>> Guenter
>>
>>
>> Hmm, this could be a Kconfig bug.
>>
>> I will take a look.
>
>
> Today, I took a look at it.
>
> The cause of the problem was the circular dependency.
>
> Somehow, 'imply' is not checked in the circular dependency.
>
> So, I wrote patches to report this.
> https://patchwork.kernel.org/patch/10565061/
> https://patchwork.kernel.org/patch/10565063/
>
>
> If you apply those two patches on top of commit
> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> It is reported in allmodconfig stage, like this:
>
>
> masahiro@grover:~/ref/linux-next$ make allmodconfig
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --allmodconfig Kconfig
> drivers/of/Kconfig:68:error: recursive dependency detected!
> drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
> kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
> drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED
> drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON
> drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP
> drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB
> drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
> drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected
> by ARC_EMAC
> drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
>
Interesting; I thought that "implied" does not really select the symbol.
That means 'imply' just doesn't work for HWMON, and we'll have to stick
with the old "depends on HWMON || HWMON=n".
Thanks,
Guenter
^ permalink raw reply
* Re: [RFC PATCH net-next V2 6/6] virtio-net: support XDP rx handler
From: Jason Wang @ 2018-08-14 13:01 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <20180814112222.42177a24@redhat.com>
On 2018年08月14日 17:22, Jesper Dangaard Brouer wrote:
> On Mon, 13 Aug 2018 11:17:30 +0800
> Jason Wang<jasowang@redhat.com> wrote:
>
>> This patch tries to add the support of XDP rx handler to
>> virtio-net. This is straight-forward, just call xdp_do_pass() and
>> behave depends on its return value.
>>
>> Test was done by using XDP_DROP (xdp1) for macvlan on top of
>> virtio-net. PPS of SKB mode was ~1.2Mpps while PPS of native XDP mode
>> was ~2.2Mpps. About 83% improvement was measured.
> I'm not convinced...
>
> Why are you not using XDP_REDIRECT, which is already implemented in
> receive_mergeable (which you modify below).
>
> The macvlan driver just need to implement ndo_xdp_xmit(), and then you
> can redirect (with XDP prog from physical driver into the guest). It
> should be much faster...
>
>
Macvlan is different from macvtap. For host RX, macvtap deliver the
packet to a pointer ring which could be accessed through a socket but
macvlan deliver the packet to the normal networking stack. As an example
of XDP rx handler, this series just try to make native XDP works for
macvlan, macvtap path will still go for skb (but it's not hard to add it
on top).
Consider the case of fast forwarding between host and guest. For TAP,
XDP_REDIRECT works perfectly since from the host point of view, host RX
is guest TX and host guest RX is host TX. But for macvtap which is based
on macvlan, transmitting packet to macvtap/macvlan means transmitting
packets to under layer device which is either a physical NIC or another
macvlan device. That's why we can't use XDP_REDIRECT with ndo_xdp_xmit().
Thanks
^ permalink raw reply
* Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Alexandre Belloni @ 2018-08-14 12:45 UTC (permalink / raw)
To: Rob Herring
Cc: Quentin Schulz, Florian Fainelli, ralf, paul.burton, jhogan,
mark.rutland, davem, kishon, andrew, linux-mips, devicetree,
linux-kernel, netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180813223748.GA20086@rob-hp-laptop>
On 13/08/2018 16:37:48-0600, Rob Herring wrote:
> > I'm fine with a define for the second value (which is basically the enum
> > serdes_type I've defined at the beginning of the serdes driver) but I
> > don't see the point of defining the index of the SerDes. What would it
> > look like?
> >
> > enum serdes_type {
> > SERDES1G = 1,
> > SERDES6G = 6,
> > }
> >
> > #define SERDES1G_0 0
> > #define SERDES1G_1 1
> > #define SERDES1G_2 2
> > #define SERDES6G_0 0
> > #define SERDES6G_1 1
> >
> > Then, e.g.:
> >
> > &port5 {
> > phys = <&serdes 5 SERDES1G SERDES1G_0>
> > };
> >
> > If you want a define for the pair (serdes_type, serdes_index), I don't
> > see how I could re-use it on the driver side but it makes more sense on the
> > DeviceTree side:
> >
> > #define SERDES1G_0 1 0
> > #define SERDES1G_1 1 1
> > #define SERDES1G_2 1 2
> > #define SERDES6G_0 6 0
> > #define SERDES6G_1 6 1
>
> I prefer #defines which are a single number. Otherwise if you read a dts
> file when #phy-cells is 3, it will look like an error in that you have
> what looks like 2 cells.
>
Maybe we should not have the type in DT and simply have an index. The
driver will now what the serdes type is anyway and the defines would be:
#define SERDES1G_0 0
#define SERDES1G_1 1
#define SERDES1G_2 2
#define SERDES6G_0 3
#define SERDES6G_1 4
The main drawback is that this requires one include file per soc.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Alexandre Belloni @ 2018-08-14 12:41 UTC (permalink / raw)
To: Quentin Schulz
Cc: Rob Herring, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180814064953.vboz2gryq4jff34n@qschulz>
On 14/08/2018 08:49:53+0200, Quentin Schulz wrote:
> Understood but it's an intermediate patch. Later (patch 8), the SerDes
> muxing "controller" is added as a child to this node. There most likely
> will be some others in the future (temperature sensor for example).
>
> Furthermore, there's already a simple-mfd without children in this file:
> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
>
> How should we handle this case?
>
There were child nodes in previous version of the binding. You can
remove simple-mfd now. The useful registers that are not used by any
drivers are gpr and chipid.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] dt-bindings: net: ravb: Add support for r8a774a1 SoC
From: Fabrizio Castro @ 2018-08-14 12:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Fabrizio Castro, Sergei Shtylyov, David S. Miller,
Geert Uytterhoeven, Simon Horman, Biju Das, Yoshihiro Shimoda,
netdev, linux-renesas-soc, devicetree, linux-kernel, Simon Horman,
Chris Paterson
Document RZ/G2M (R8A774A1) SoC bindings.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
---
Documentation/devicetree/bindings/net/renesas,ravb.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt
index 19740d0..da249b7 100644
--- a/Documentation/devicetree/bindings/net/renesas,ravb.txt
+++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt
@@ -16,6 +16,7 @@ Required properties:
- "renesas,etheravb-rcar-gen2" as a fallback for the above
R-Car Gen2 and RZ/G1 devices.
+ - "renesas,etheravb-r8a774a1" for the R8A774A1 SoC.
- "renesas,etheravb-r8a7795" for the R8A7795 SoC.
- "renesas,etheravb-r8a7796" for the R8A7796 SoC.
- "renesas,etheravb-r8a77965" for the R8A77965 SoC.
@@ -24,7 +25,7 @@ Required properties:
- "renesas,etheravb-r8a77990" for the R8A77990 SoC.
- "renesas,etheravb-r8a77995" for the R8A77995 SoC.
- "renesas,etheravb-rcar-gen3" as a fallback for the above
- R-Car Gen3 devices.
+ R-Car Gen3 and RZ/G2 devices.
When compatible with the generic version, nodes must list the
SoC-specific version corresponding to the platform first followed by
--
2.7.4
^ permalink raw reply related
* [PATCH net] cls_matchall: fix tcf_unbind_filter missing
From: Hangbin Liu @ 2018-08-14 9:28 UTC (permalink / raw)
To: netdev; +Cc: David Miller, WANG Cong, Yotam Gigi, Jiri Pirko, Hangbin Liu
Fix tcf_unbind_filter missing in cls_matchall as this will trigger
WARN_ON() in cbq_destroy_class().
Fixes: fd62d9f5c575f ("net/sched: matchall: Fix configuration race")
Reported-by: Li Shuang <shuali@redhat.com>
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/sched/cls_matchall.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
index 47b207e..7ad65da 100644
--- a/net/sched/cls_matchall.c
+++ b/net/sched/cls_matchall.c
@@ -111,6 +111,8 @@ static void mall_destroy(struct tcf_proto *tp, struct netlink_ext_ack *extack)
if (!head)
return;
+ tcf_unbind_filter(tp, &head->res);
+
if (!tc_skip_hw(head->flags))
mall_destroy_hw_filter(tp, head, (unsigned long) head, extack);
--
2.5.5
^ permalink raw reply related
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Camille Bordignon @ 2018-08-14 9:14 UTC (permalink / raw)
To: Neftin, Sasha; +Cc: Alexander Duyck, Netdev, intel-wired-lan, David S. Miller
In-Reply-To: <c1e2cf13-6bcc-498d-03ea-7c3792d675cb@intel.com>
Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> On 8/8/2018 17:24, Neftin, Sasha wrote:
> > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > <camille.bordignon@easymile.com> wrote:
> > > > > Hello,
> > > > >
> > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > and I219-V).
> > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > link speed drips to 10 Mbps.
> > > > >
> > > > > From kernel logs:
> > > > > [17616.346150] e1000e: enp0s31f6 NIC Link is Down
> > > > > [17627.003322] e1000e: enp0s31f6 NIC Link is Up 10 Mbps Full
> > > > > Duplex, Flow Control: None
> > > > > [17627.003325] e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed:
> > > > > disabling TSO
> > > > >
> > > > >
> > > > > $ethtool enp0s31f6
> > > > > Settings for enp0s31f6:
> > > > > Supported ports: [ TP ]
> > > > > Supported link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Supported pause frame use: No
> > > > > Supports auto-negotiation: Yes
> > > > > Supported FEC modes: Not reported
> > > > > Advertised link modes: 10baseT/Half 10baseT/Full
> > > > > 100baseT/Half 100baseT/Full
> > > > > 1000baseT/Full
> > > > > Advertised pause frame use: No
> > > > > Advertised auto-negotiation: Yes
> > > > > Advertised FEC modes: Not reported
> > > > > Speed: 10Mb/s
> > > > > Duplex: Full
> > > > > Port: Twisted Pair
> > > > > PHYAD: 1
> > > > > Transceiver: internal
> > > > > Auto-negotiation: on
> > > > > MDI-X: on (auto)
> > > > > Supports Wake-on: pumbg
> > > > > Wake-on: g
> > > > > Current message level: 0x00000007 (7)
> > > > > drv probe link
> > > > > Link detected: yes
> > > > >
> > > > >
> > > > > Notice that if disconnection last less than about 5 seconds,
> > > > > nothing wrong happens.
> > > > > And if after last failure, disconnection / connection occurs again and
> > > > > last less than 5 seconds, link speed is back to 1000 Mbps.
> > > > >
> > > > > [18075.350678] e1000e: enp0s31f6 NIC Link is Down
> > > > > [18078.716245] e1000e: enp0s31f6 NIC Link is Up 1000 Mbps
> > > > > Full Duplex, Flow Control: None
> > > > >
> > > > > The following patch seems to fix this issue.
> > > > > However I don't clearly understand why.
> > > > >
> > > > > diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > index 3ba0c90e7055..763c013960f1 100644
> > > > > --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> > > > > @@ -5069,7 +5069,7 @@ static bool e1000e_has_link(struct
> > > > > e1000_adapter *adapter)
> > > > > case e1000_media_type_copper:
> > > > > if (hw->mac.get_link_status) {
> > > > > ret_val = hw->mac.ops.check_for_link(hw);
> > > > > - link_active = !hw->mac.get_link_status;
> > > > > + link_active = false;
> > > > > } else {
> > > > > link_active = true;
> > > > > }
> > > > >
> > > > > Maybe this is related to watchdog task.
> > > > >
> > > > > I've found out this fix by comparing with last commit that works fine :
> > > > > commit 0b76aae741abb9d16d2c0e67f8b1e766576f897d.
> > > > > However I don't know if this information is relevant.
> > > > >
> > > > > Thank you.
> > > > > Camille Bordignon
> > > >
> > > > What kernel were you testing this on? I know there have been a number
> > > > of changes over the past few months in this area and it would be
> > > > useful to know exactly what code base you started out with and what
> > > > the latest version of the kernel is you have tested.
> > > >
> > > > Looking over the code change the net effect of it should be to add a 2
> > > > second delay from the time the link has changed until you actually
> > > > check the speed/duplex configuration. It is possible we could be
> > > > seeing some sort of timing issue and adding the 2 second delay after
> > > > the link event is enough time for things to stabilize and detect the
> > > > link at 1000 instead of 10/100.
> > > >
> > > > - Alex
> > >
> > > We've found out this issue using Fedora 27 (4.17.11-100.fc27.x86_64).
> > >
> > > Then I've tested wth a more recent version of the driver v4.18-rc7 but
> > > behavior looks the same.
> > >
> > > Thanks for you reply.
> > >
> > > Camille Bordignon
> > > _______________________________________________
> > > Intel-wired-lan mailing list
> > > Intel-wired-lan@osuosl.org
> > > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> > >
> > I've agree with Alex. Let's try add 2s delay after a link event. Please,
> > let us know if it will solve your problem.
> > Also, I would like recommend try work with different link partner and
> > see if you see same problem.
> > _______________________________________________
> > Intel-wired-lan mailing list
> > Intel-wired-lan@osuosl.org
> > https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> Camille,
> My apologies, I wrong understand Alex. Please, do not try add delay. Please,
> check if you see same problem with different link partners.
> Thanks,
> Sasha
I tried to reproduce the issue with differents devices.
On computer side :
- HP ZBook 14u G5 (Intel NIC I219-V)
- Dell Tower 3620 (Intel NIC I219-LM)
On network side :
- TP-LINK TL-SG108E
- Advantech EKI-2728I
- Freebox v6 (https://en.wikipedia.org/wiki/Freebox)
It always happens with any configuration.
Thanks.
Camille Bordignon
^ permalink raw reply
* [PATCH net-next] net: dsa: mv88e6xxx: missing unlock on error path
From: Dan Carpenter @ 2018-08-14 9:09 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Vivien Didelot, Florian Fainelli, netdev, kernel-janitors
We added a new error path, but we need to drop the lock before we return.
Fixes: 2d2e1dd29962 ("net: dsa: mv88e6xxx: Cache the port cmode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 17752316ab10..8da3d39e3218 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2408,7 +2408,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
if (chip->info->ops->port_get_cmode) {
err = chip->info->ops->port_get_cmode(chip, i, &cmode);
if (err)
- return err;
+ goto unlock;
chip->ports[i].cmode = cmode;
}
^ permalink raw reply related
* [PATCH net-next] net: dsa: mv88e6xxx: bitwise vs logical bug
From: Dan Carpenter @ 2018-08-14 9:06 UTC (permalink / raw)
To: Andrew Lunn
Cc: Vivien Didelot, Florian Fainelli, David S. Miller, netdev,
kernel-janitors
We are trying to test if these flags are set but there are some && vs &
typos.
Fixes: efd1ba6af93f ("net: dsa: mv88e6xxx: Add SERDES phydev_mac_change up for 6390")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/dsa/mv88e6xxx/serdes.c b/drivers/net/dsa/mv88e6xxx/serdes.c
index f007d109b385..e82983975754 100644
--- a/drivers/net/dsa/mv88e6xxx/serdes.c
+++ b/drivers/net/dsa/mv88e6xxx/serdes.c
@@ -502,8 +502,8 @@ static irqreturn_t mv88e6390_serdes_thread_fn(int irq, void *dev_id)
err = mv88e6390_serdes_irq_status_sgmii(chip, lane, &status);
if (err)
goto out;
- if (status && (MV88E6390_SGMII_INT_LINK_DOWN ||
- MV88E6390_SGMII_INT_LINK_UP)) {
+ if (status & (MV88E6390_SGMII_INT_LINK_DOWN |
+ MV88E6390_SGMII_INT_LINK_UP)) {
ret = IRQ_HANDLED;
mv88e6390_serdes_irq_link_sgmii(chip, port->port, lane);
}
^ permalink raw reply related
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