* memory leak in internal_dev_create
From: syzbot @ 2019-08-06 8:58 UTC (permalink / raw)
To: davem, dev, linux-kernel, netdev, pshelar, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 1e78030e Merge tag 'mmc-v5.3-rc1' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=148d3d1a600000
kernel config: https://syzkaller.appspot.com/x/.config?x=30cef20daf3e9977
dashboard link: https://syzkaller.appspot.com/bug?extid=13210896153522fe1ee5
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=136aa8c4600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=109ba792600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+13210896153522fe1ee5@syzkaller.appspotmail.com
BUG: memory leak
unreferenced object 0xffff8881207e4100 (size 128):
comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
hex dump (first 32 bytes):
00 70 16 18 81 88 ff ff 80 af 8c 22 81 88 ff ff .p........."....
00 b6 23 17 81 88 ff ff 00 00 00 00 00 00 00 00 ..#.............
backtrace:
[<000000000eb78212>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000000eb78212>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000000eb78212>] slab_alloc mm/slab.c:3319 [inline]
[<000000000eb78212>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000006ea6c6>] kmalloc include/linux/slab.h:552 [inline]
[<00000000006ea6c6>] kzalloc include/linux/slab.h:748 [inline]
[<00000000006ea6c6>] ovs_vport_alloc+0x37/0xf0
net/openvswitch/vport.c:130
[<00000000f9a04a7d>] internal_dev_create+0x24/0x1d0
net/openvswitch/vport-internal_dev.c:164
[<0000000056ee7c13>] ovs_vport_add+0x81/0x190
net/openvswitch/vport.c:199
[<000000005434efc7>] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
[<00000000b7b253f1>] ovs_dp_cmd_new+0x22f/0x410
net/openvswitch/datapath.c:1614
[<00000000e0988518>] genl_family_rcv_msg+0x2ab/0x5b0
net/netlink/genetlink.c:629
[<00000000d0cc9347>] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
[<000000006694b647>] netlink_rcv_skb+0x61/0x170
net/netlink/af_netlink.c:2477
[<0000000088381f37>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
[<00000000dad42a47>] netlink_unicast_kernel
net/netlink/af_netlink.c:1302 [inline]
[<00000000dad42a47>] netlink_unicast+0x1ec/0x2d0
net/netlink/af_netlink.c:1328
[<0000000067e6b079>] netlink_sendmsg+0x270/0x480
net/netlink/af_netlink.c:1917
[<00000000aab08a47>] sock_sendmsg_nosec net/socket.c:637 [inline]
[<00000000aab08a47>] sock_sendmsg+0x54/0x70 net/socket.c:657
[<000000004cb7c11d>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
[<00000000c4901c63>] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
[<00000000c10abb2d>] __do_sys_sendmsg net/socket.c:2365 [inline]
[<00000000c10abb2d>] __se_sys_sendmsg net/socket.c:2363 [inline]
[<00000000c10abb2d>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363
BUG: memory leak
unreferenced object 0xffff88811723b600 (size 64):
comm "syz-executor032", pid 7014, jiffies 4294944027 (age 13.830s)
hex dump (first 32 bytes):
01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 02 00 00 00 05 35 82 c1 .............5..
backtrace:
[<00000000352f46d8>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000352f46d8>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000352f46d8>] slab_alloc mm/slab.c:3319 [inline]
[<00000000352f46d8>] __do_kmalloc mm/slab.c:3653 [inline]
[<00000000352f46d8>] __kmalloc+0x169/0x300 mm/slab.c:3664
[<000000008e48f3d1>] kmalloc include/linux/slab.h:557 [inline]
[<000000008e48f3d1>] ovs_vport_set_upcall_portids+0x54/0xd0
net/openvswitch/vport.c:343
[<00000000541e4f4a>] ovs_vport_alloc+0x7f/0xf0
net/openvswitch/vport.c:139
[<00000000f9a04a7d>] internal_dev_create+0x24/0x1d0
net/openvswitch/vport-internal_dev.c:164
[<0000000056ee7c13>] ovs_vport_add+0x81/0x190
net/openvswitch/vport.c:199
[<000000005434efc7>] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
[<00000000b7b253f1>] ovs_dp_cmd_new+0x22f/0x410
net/openvswitch/datapath.c:1614
[<00000000e0988518>] genl_family_rcv_msg+0x2ab/0x5b0
net/netlink/genetlink.c:629
[<00000000d0cc9347>] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
[<000000006694b647>] netlink_rcv_skb+0x61/0x170
net/netlink/af_netlink.c:2477
[<0000000088381f37>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
[<00000000dad42a47>] netlink_unicast_kernel
net/netlink/af_netlink.c:1302 [inline]
[<00000000dad42a47>] netlink_unicast+0x1ec/0x2d0
net/netlink/af_netlink.c:1328
[<0000000067e6b079>] netlink_sendmsg+0x270/0x480
net/netlink/af_netlink.c:1917
[<00000000aab08a47>] sock_sendmsg_nosec net/socket.c:637 [inline]
[<00000000aab08a47>] sock_sendmsg+0x54/0x70 net/socket.c:657
[<000000004cb7c11d>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
[<00000000c4901c63>] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
BUG: memory leak
unreferenced object 0xffff8881228ca500 (size 128):
comm "syz-executor032", pid 7015, jiffies 4294944622 (age 7.880s)
hex dump (first 32 bytes):
00 f0 27 18 81 88 ff ff 80 ac 8c 22 81 88 ff ff ..'........"....
40 b7 23 17 81 88 ff ff 00 00 00 00 00 00 00 00 @.#.............
backtrace:
[<000000000eb78212>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000000eb78212>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000000eb78212>] slab_alloc mm/slab.c:3319 [inline]
[<000000000eb78212>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000006ea6c6>] kmalloc include/linux/slab.h:552 [inline]
[<00000000006ea6c6>] kzalloc include/linux/slab.h:748 [inline]
[<00000000006ea6c6>] ovs_vport_alloc+0x37/0xf0
net/openvswitch/vport.c:130
[<00000000f9a04a7d>] internal_dev_create+0x24/0x1d0
net/openvswitch/vport-internal_dev.c:164
[<0000000056ee7c13>] ovs_vport_add+0x81/0x190
net/openvswitch/vport.c:199
[<000000005434efc7>] new_vport+0x19/0x80 net/openvswitch/datapath.c:194
[<00000000b7b253f1>] ovs_dp_cmd_new+0x22f/0x410
net/openvswitch/datapath.c:1614
[<00000000e0988518>] genl_family_rcv_msg+0x2ab/0x5b0
net/netlink/genetlink.c:629
[<00000000d0cc9347>] genl_rcv_msg+0x54/0x9c net/netlink/genetlink.c:654
[<000000006694b647>] netlink_rcv_skb+0x61/0x170
net/netlink/af_netlink.c:2477
[<0000000088381f37>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:665
[<00000000dad42a47>] netlink_unicast_kernel
net/netlink/af_netlink.c:1302 [inline]
[<00000000dad42a47>] netlink_unicast+0x1ec/0x2d0
net/netlink/af_netlink.c:1328
[<0000000067e6b079>] netlink_sendmsg+0x270/0x480
net/netlink/af_netlink.c:1917
[<00000000aab08a47>] sock_sendmsg_nosec net/socket.c:637 [inline]
[<00000000aab08a47>] sock_sendmsg+0x54/0x70 net/socket.c:657
[<000000004cb7c11d>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2311
[<00000000c4901c63>] __sys_sendmsg+0x80/0xf0 net/socket.c:2356
[<00000000c10abb2d>] __do_sys_sendmsg net/socket.c:2365 [inline]
[<00000000c10abb2d>] __se_sys_sendmsg net/socket.c:2363 [inline]
[<00000000c10abb2d>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2363
---
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#status 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
* [PATCH] net: cxgb3_main: Fix a resource leak in a error path in 'init_one()'
From: Christophe JAILLET @ 2019-08-06 8:55 UTC (permalink / raw)
To: vishal, davem; +Cc: netdev, linux-kernel, kernel-janitors, Christophe JAILLET
A call to 'kfree_skb()' is missing in the error handling path of
'init_one()'.
This is already present in 'remove_one()' but is missing here.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 1e82b9efe447..58f89f6a040f 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -3269,7 +3269,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (!adapter->regs) {
dev_err(&pdev->dev, "cannot map device registers\n");
err = -ENOMEM;
- goto out_free_adapter;
+ goto out_free_adapter_nofail;
}
adapter->pdev = pdev;
@@ -3397,6 +3397,9 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
if (adapter->port[i])
free_netdev(adapter->port[i]);
+out_free_adapter_nofail:
+ kfree_skb(adapter->nofail_skb);
+
out_free_adapter:
kfree(adapter);
--
2.20.1
^ permalink raw reply related
* [PATCH net v2] net: dsa: Check existence of .port_mdb_add callback before calling it
From: Chen-Yu Tsai @ 2019-08-06 7:53 UTC (permalink / raw)
To: Andrew Lunn, Vivien Didelot, Florian Fainelli, David S. Miller
Cc: Chen-Yu Tsai, netdev, linux-kernel
From: Chen-Yu Tsai <wens@csie.org>
With the recent addition of commit 75dad2520fc3 ("net: dsa: b53: Disable
all ports on setup"), users of b53 (BCM53125 on Lamobo R1 in my case)
are forced to use the dsa subsystem to enable the switch, instead of
having it in the default transparent "forward-to-all" mode.
The b53 driver does not support mdb bitmap functions. However the dsa
layer does not check for the existence of the .port_mdb_add callback
before actually using it. This results in a NULL pointer dereference,
as shown in the kernel oops below.
The other functions seem to be properly guarded. Do the same for
.port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
b53 is not the only driver that doesn't support mdb bitmap functions.
Others include bcm_sf2, dsa_loop, lantiq_gswip, mt7530, mv88e6060,
qca8k, realtek-smi, and vitesse-vsc73xx.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = (ptrval)
[00000000] *pgd=00000000
Internal error: Oops: 80000005 [#1] SMP ARM
Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211
CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a #1
Hardware name: Allwinner sun7i (A20) Family
Workqueue: events switchdev_deferred_process_work
PC is at 0x0
LR is at dsa_switch_event+0x570/0x620
pc : [<00000000>] lr : [<c08533ec>] psr: 80070013
sp : ee871db8 ip : 00000000 fp : ee98d0a4
r10: 0000000c r9 : 00000008 r8 : ee89f710
r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
r3 : 00000000 r2 : ee89f710 r1 : 00000008 r0 : ee98d040
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 6deb406a DAC: 00000051
Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
Stack: (0xee871db8 to 0xee872000)
1da0: ee871e14 103ace2d
1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
[<c014bdfc>] (notifier_call_chain) from [<c014bef0>] (raw_notifier_call_chain+0x18/0x20)
[<c014bef0>] (raw_notifier_call_chain) from [<c08509a8>] (dsa_port_mdb_add+0x48/0x74)
[<c08509a8>] (dsa_port_mdb_add) from [<c087e248>] (__switchdev_handle_port_obj_add+0x54/0xd4)
[<c087e248>] (__switchdev_handle_port_obj_add) from [<c087e2d0>] (switchdev_handle_port_obj_add+0x8/0x14)
[<c087e2d0>] (switchdev_handle_port_obj_add) from [<c08523c4>] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
[<c08523c4>] (dsa_slave_switchdev_blocking_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
[<c014bdfc>] (notifier_call_chain) from [<c014c500>] (blocking_notifier_call_chain+0x50/0x68)
[<c014c500>] (blocking_notifier_call_chain) from [<c087dfb4>] (switchdev_port_obj_notify+0x44/0xa8)
[<c087dfb4>] (switchdev_port_obj_notify) from [<c087e0a8>] (switchdev_port_obj_add_now+0x90/0x104)
[<c087e0a8>] (switchdev_port_obj_add_now) from [<c087e130>] (switchdev_port_obj_add_deferred+0x14/0x5c)
[<c087e130>] (switchdev_port_obj_add_deferred) from [<c087de4c>] (switchdev_deferred_process+0x64/0x104)
[<c087de4c>] (switchdev_deferred_process) from [<c087def8>] (switchdev_deferred_process_work+0xc/0x14)
[<c087def8>] (switchdev_deferred_process_work) from [<c01447dc>] (process_one_work+0x218/0x50c)
[<c01447dc>] (process_one_work) from [<c0145b84>] (worker_thread+0x44/0x5bc)
[<c0145b84>] (worker_thread) from [<c014a6f8>] (kthread+0x148/0x150)
[<c014a6f8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
Exception stack(0xee871fb0 to 0xee871ff8)
1fa0: 00000000 00000000 00000000 00000000
1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Code: bad PC value
---[ end trace 1292c61abd17b130 ]---
[<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
corresponds to
$ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
linux/net/dsa/switch.c:156
linux/net/dsa/switch.c:178
linux/net/dsa/switch.c:328
Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
Changes since v1:
- Moved the check to the beginning of dsa_switch_mdb_add()
Looks like we could also move the ops check out of
dsa_switch_mdb_prepare_bitmap(), though I suppose keeping the code the
way it is now is clearer.
---
net/dsa/switch.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/dsa/switch.c b/net/dsa/switch.c
index 4ec5b7f85d51..231af5268656 100644
--- a/net/dsa/switch.c
+++ b/net/dsa/switch.c
@@ -164,6 +164,9 @@ static int dsa_switch_mdb_add(struct dsa_switch *ds,
struct switchdev_trans *trans = info->trans;
int port;
+ if (!ds->ops->port_mdb_add)
+ return -EOPNOTSUPP;
+
/* Build a mask of Multicast group members */
bitmap_zero(ds->bitmap, ds->num_ports);
if (ds->index == info->sw_index)
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next v2 3/4] IB/mlx5: Expose ODP for DC capabilities to user
From: Leon Romanovsky @ 2019-08-06 7:48 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Michael Guralnik, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190806074807.9111-1-leon@kernel.org>
From: Michael Guralnik <michaelgur@mellanox.com>
Return ODP capabilities for DC to user in alloc_context.
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/main.c | 6 ++++++
include/uapi/rdma/mlx5-abi.h | 3 +++
2 files changed, 9 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/main.c b/drivers/infiniband/hw/mlx5/main.c
index 4a3d700cd783..a53e0dc7c17f 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -1954,6 +1954,12 @@ static int mlx5_ib_alloc_ucontext(struct ib_ucontext *uctx,
resp.response_length += sizeof(resp.dump_fill_mkey);
}
+ if (field_avail(typeof(resp), dc_odp_caps, udata->outlen)) {
+ resp.dc_odp_caps = dev->dc_odp_caps;
+ resp.comp_mask |= MLX5_IB_ALLOC_UCONTEXT_RESP_MASK_DC_ODP_CAPS;
+ resp.response_length += sizeof(resp.dc_odp_caps);
+ }
+
err = ib_copy_to_udata(udata, &resp, resp.response_length);
if (err)
goto out_mdev;
diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
index 624f5b53eb1f..7cab806d7fa7 100644
--- a/include/uapi/rdma/mlx5-abi.h
+++ b/include/uapi/rdma/mlx5-abi.h
@@ -98,6 +98,7 @@ struct mlx5_ib_alloc_ucontext_req_v2 {
enum mlx5_ib_alloc_ucontext_resp_mask {
MLX5_IB_ALLOC_UCONTEXT_RESP_MASK_CORE_CLOCK_OFFSET = 1UL << 0,
MLX5_IB_ALLOC_UCONTEXT_RESP_MASK_DUMP_FILL_MKEY = 1UL << 1,
+ MLX5_IB_ALLOC_UCONTEXT_RESP_MASK_DC_ODP_CAPS = 1UL << 2,
};
enum mlx5_user_cmds_supp_uhw {
@@ -147,6 +148,8 @@ struct mlx5_ib_alloc_ucontext_resp {
__u32 num_uars_per_page;
__u32 num_dyn_bfregs;
__u32 dump_fill_mkey;
+ __u32 dc_odp_caps;
+ __u32 reserved;
};
struct mlx5_ib_alloc_pd_resp {
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next v2 4/4] IB/mlx5: Add page fault handler for DC initiator WQE
From: Leon Romanovsky @ 2019-08-06 7:48 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Michael Guralnik, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190806074807.9111-1-leon@kernel.org>
From: Michael Guralnik <michaelgur@mellanox.com>
Parsing DC initiator WQEs upon page fault requires skipping an address
vector segment, as in UD WQEs.
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/odp.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index 5e87a5e25574..6f1de5edbe8e 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -1065,6 +1065,12 @@ static int mlx5_ib_mr_initiator_pfault_handler(
case IB_QPT_UD:
transport_caps = dev->odp_caps.per_transport_caps.ud_odp_caps;
break;
+ case IB_QPT_DRIVER:
+ if (qp->qp_sub_type == MLX5_IB_QPT_DCI) {
+ transport_caps = dev->dc_odp_caps;
+ break;
+ }
+ /* fall through */
default:
mlx5_ib_err(dev, "ODP fault on QP of an unsupported transport 0x%x\n",
qp->ibqp.qp_type);
@@ -1078,7 +1084,8 @@ static int mlx5_ib_mr_initiator_pfault_handler(
return -EFAULT;
}
- if (qp->ibqp.qp_type == IB_QPT_UD) {
+ if (qp->ibqp.qp_type == IB_QPT_UD ||
+ qp->qp_sub_type == MLX5_IB_QPT_DCI) {
av = *wqe;
if (av->dqp_dct & cpu_to_be32(MLX5_EXTENDED_UD_AV))
*wqe += sizeof(struct mlx5_av);
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next v2 2/4] IB/mlx5: Query ODP capabilities for DC
From: Leon Romanovsky @ 2019-08-06 7:48 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Michael Guralnik, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190806074807.9111-1-leon@kernel.org>
From: Michael Guralnik <michaelgur@mellanox.com>
Cache current ODP capabilities for DC in mlx5_ib device.
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
drivers/infiniband/hw/mlx5/odp.c | 18 ++++++++++++++++++
2 files changed, 19 insertions(+)
diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
index cb41a7e6255a..f99c71b3c876 100644
--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
+++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
@@ -967,6 +967,7 @@ struct mlx5_ib_dev {
struct mutex slow_path_mutex;
int fill_delay;
struct ib_odp_caps odp_caps;
+ uint32_t dc_odp_caps;
u64 odp_max_size;
struct mlx5_ib_pf_eq odp_pf_eq;
diff --git a/drivers/infiniband/hw/mlx5/odp.c b/drivers/infiniband/hw/mlx5/odp.c
index b0c5de39d186..5e87a5e25574 100644
--- a/drivers/infiniband/hw/mlx5/odp.c
+++ b/drivers/infiniband/hw/mlx5/odp.c
@@ -353,6 +353,24 @@ void mlx5_ib_internal_fill_odp_caps(struct mlx5_ib_dev *dev)
if (MLX5_CAP_ODP(dev->mdev, xrc_odp_caps.srq_receive))
caps->per_transport_caps.xrc_odp_caps |= IB_ODP_SUPPORT_SRQ_RECV;
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.send))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_SEND;
+
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.receive))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_RECV;
+
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.write))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_WRITE;
+
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.read))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_READ;
+
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.atomic))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_ATOMIC;
+
+ if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.srq_receive))
+ dev->dc_odp_caps |= IB_ODP_SUPPORT_SRQ_RECV;
+
if (MLX5_CAP_GEN(dev->mdev, fixed_buffer_size) &&
MLX5_CAP_GEN(dev->mdev, null_mkey) &&
MLX5_CAP_GEN(dev->mdev, umr_extended_translation_offset))
--
2.20.1
^ permalink raw reply related
* [PATCH mlx5-next v2 1/4] net/mlx5: Set ODP capabilities for DC transport
From: Leon Romanovsky @ 2019-08-06 7:48 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Michael Guralnik, Moni Shoua,
Saeed Mahameed, linux-netdev
In-Reply-To: <20190806074807.9111-1-leon@kernel.org>
From: Michael Guralnik <michaelgur@mellanox.com>
Query ODP capabilities for DC transport from FW.
Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 ++++++
include/linux/mlx5/mlx5_ifc.h | 4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index b15b27a497fc..3995fc6d4d34 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -495,6 +495,12 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev)
ODP_CAP_SET_MAX(dev, xrc_odp_caps.write);
ODP_CAP_SET_MAX(dev, xrc_odp_caps.read);
ODP_CAP_SET_MAX(dev, xrc_odp_caps.atomic);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.srq_receive);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.send);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.receive);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.write);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.read);
+ ODP_CAP_SET_MAX(dev, dc_odp_caps.atomic);
if (do_set)
err = set_caps(dev, set_ctx, set_sz,
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index ec571fd7fcf8..b96d5c37f70f 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -944,7 +944,9 @@ struct mlx5_ifc_odp_cap_bits {
struct mlx5_ifc_odp_per_transport_service_cap_bits xrc_odp_caps;
- u8 reserved_at_100[0x700];
+ struct mlx5_ifc_odp_per_transport_service_cap_bits dc_odp_caps;
+
+ u8 reserved_at_120[0x6E0];
};
struct mlx5_ifc_calc_op {
--
2.20.1
^ permalink raw reply related
* [PATCH rdma-next v2 0/4] ODP support for mlx5 DC QPs
From: Leon Romanovsky @ 2019-08-06 7:48 UTC (permalink / raw)
To: Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Michael Guralnik, Moni Shoua,
Saeed Mahameed, linux-netdev
From: Leon Romanovsky <leonro@mellanox.com>
Changelog
v2:
* Fixed reserved_* field wrong name (Saeed M.)
* Split first patch to two patches, one for mlx5-next and one for rdma-next. (Saeed M.)
v1:
* Fixed alignment to u64 in mlx5-abi.h (Gal P.)
* https://lore.kernel.org/linux-rdma/20190804100048.32671-1-leon@kernel.org
v0:
* https://lore.kernel.org/linux-rdma/20190801122139.25224-1-leon@kernel.org
---------------------------------------------------------------------------------
From Michael,
The series adds support for on-demand paging for DC transport.
Adding handling of DC WQE parsing upon page faults and exposing
capabilities.
As DC is mlx-only transport, the capabilities are exposed to the user
using the direct-verbs mechanism. Namely through the
mlx5dv_query_device.
Thanks
Michael Guralnik (4):
net/mlx5: Set ODP capabilities for DC transport
IB/mlx5: Query ODP capabilities for DC
IB/mlx5: Expose ODP for DC capabilities to user
IB/mlx5: Add page fault handler for DC initiator WQE
drivers/infiniband/hw/mlx5/main.c | 6 +++++
drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
drivers/infiniband/hw/mlx5/odp.c | 27 ++++++++++++++++++-
.../net/ethernet/mellanox/mlx5/core/main.c | 6 +++++
include/linux/mlx5/mlx5_ifc.h | 4 ++-
include/uapi/rdma/mlx5-abi.h | 3 +++
6 files changed, 45 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH net] net: ethernet: sun4i-emac: Support phy-handle property for finding PHYs
From: Chen-Yu Tsai @ 2019-08-06 7:35 UTC (permalink / raw)
To: David S. Miller, Maxime Ripard
Cc: Chen-Yu Tsai, netdev, linux-arm-kernel, linux-kernel
From: Chen-Yu Tsai <wens@csie.org>
The sun4i-emac uses the "phy" property to find the PHY it's supposed to
use. This property was deprecated in favor of "phy-handle" in commit
8c5b09447625 ("dt-bindings: net: sun4i-emac: Convert the binding to a
schemas").
Add support for this new property name, and fall back to the old one in
case the device tree hasn't been updated.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
The aforementioned commit is in v5.3-rc1. It would be nice to have the
driver fix in the same release. In addition, an update for the device
tree has been queued up for v5.4, which made us realize the driver needs
an update.
---
drivers/net/ethernet/allwinner/sun4i-emac.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/allwinner/sun4i-emac.c b/drivers/net/ethernet/allwinner/sun4i-emac.c
index 3434730a7699..0537df06a9b5 100644
--- a/drivers/net/ethernet/allwinner/sun4i-emac.c
+++ b/drivers/net/ethernet/allwinner/sun4i-emac.c
@@ -860,7 +860,9 @@ static int emac_probe(struct platform_device *pdev)
goto out_clk_disable_unprepare;
}
- db->phy_node = of_parse_phandle(np, "phy", 0);
+ db->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (!db->phy_node)
+ db->phy_node = of_parse_phandle(np, "phy", 0);
if (!db->phy_node) {
dev_err(&pdev->dev, "no associated PHY\n");
ret = -ENODEV;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 15/16] net: phy: adin: add ethtool get_stats support
From: Ardelean, Alexandru @ 2019-08-06 7:18 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805153058.GU24275@lunn.ch>
On Mon, 2019-08-05 at 17:30 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:52PM +0300, Alexandru Ardelean wrote:
> > This change implements retrieving all the error counters from the PHY.
> > The PHY supports several error counters/stats. The `Mean Square Errors`
> > status values are only valie when a link is established, and shouldn't be
> > incremented. These values characterize the quality of a signal.
>
> I think you mean accumulated, not incremented?
accumulated sounds better;
> > The rest of the error counters are self-clearing on read.
> > Most of them are reports from the Frame Checker engine that the PHY has.
> >
> > Not retrieving the `LPI Wake Error Count Register` here, since that is used
> > by the PHY framework to check for any EEE errors. And that register is
> > self-clearing when read (as per IEEE spec).
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 108 +++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 108 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index a1f3456a8504..04896547dac8 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -103,6 +103,32 @@ static struct clause22_mmd_map clause22_mmd_map[] = {
> > { MDIO_MMD_PCS, MDIO_PCS_EEE_WK_ERR, ADIN1300_LPI_WAKE_ERR_CNT_REG },
> > };
> >
> > +struct adin_hw_stat {
> > + const char *string;
> > + u16 reg1;
> > + u16 reg2;
> > + bool do_not_inc;
>
> do_not_accumulate? or reverse its meaning, clear_on_read?
do_not_accumulate works;
there are only 4 regs that need this property set to true
>
> Andrew
^ permalink raw reply
* Re: [PATCH 15/16] net: phy: adin: add ethtool get_stats support
From: Ardelean, Alexandru @ 2019-08-06 7:11 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805152832.GT24275@lunn.ch>
On Mon, 2019-08-05 at 17:28 +0200, Andrew Lunn wrote:
> [External]
>
> > +struct adin_hw_stat {
> > + const char *string;
> > +static void adin_get_strings(struct phy_device *phydev, u8 *data)
> > +{
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(adin_hw_stats); i++) {
> > + memcpy(data + i * ETH_GSTRING_LEN,
> > + adin_hw_stats[i].string, ETH_GSTRING_LEN);
>
> You define string as a char *. So it will be only as long as it should
> be. However memcpy always copies ETH_GSTRING_LEN bytes, doing off the
> end of the string and into whatever follows.
>
hmm, will use strlcpy()
i blindedly copied memcpy() from some other driver
>
> > + }
> > +}
> > +
> > +static int adin_read_mmd_stat_regs(struct phy_device *phydev,
> > + struct adin_hw_stat *stat,
> > + u32 *val)
> > +{
> > + int ret;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg1);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val = (ret & 0xffff);
> > +
> > + if (stat->reg2 == 0)
> > + return 0;
> > +
> > + ret = phy_read_mmd(phydev, MDIO_MMD_VEND1, stat->reg2);
> > + if (ret < 0)
> > + return ret;
> > +
> > + *val <<= 16;
> > + *val |= (ret & 0xffff);
>
> Does the hardware have a snapshot feature? Is there a danger that
> between the two reads stat->reg1 rolls over and you end up with too
> big a value?
i'm afraid i don't understand about the snapshot feature you are mentioning;
i.e. i don't remember seeing it in other chips;
regarding the danger that stat->reg1 rolls over, i guess that is possible, but it's a bit hard to guard against;
i guess if it ends up in that scenario, [for many counters] things would be horribly bad, and the chip, or cabling would
be unusable;
not sure if this answer is sufficient/satisfactory;
thanks
>
> Andrew
^ permalink raw reply
* Re: [PATCH 16/16] dt-bindings: net: add bindings for ADIN PHY driver
From: Ardelean, Alexandru @ 2019-08-06 7:03 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805141100.GG24275@lunn.ch>
On Mon, 2019-08-05 at 16:11 +0200, Andrew Lunn wrote:
> [External]
>
> > + adi,rx-internal-delay:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + RGMII RX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> > + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> > + default value is 0 (which represents 2 ns)
> > + enum: [ 0, 1, 2, 6, 7 ]
>
> We want these numbers to be in ns. So the default value would actually
> be 2. The driver needs to convert the number in DT to a value to poke
> into a PHY register. Please rename the property adi,rx-internal-delay-ns.
ack;
also, good point about ns units and PHY driver to convert it to reg values;
>
> > +
> > + adi,tx-internal-delay:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + RGMII TX Clock Delay used only when PHY operates in RGMII mode (phy-mode
> > + is "rgmii-id", "rgmii-rxid", "rgmii-txid") see `dt-bindings/net/adin.h`
> > + default value is 0 (which represents 2 ns)
> > + enum: [ 0, 1, 2, 6, 7 ]
>
> Same here.
>
> > +
> > + adi,fifo-depth:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + When operating in RMII mode, this option configures the FIFO depth.
> > + See `dt-bindings/net/adin.h`.
> > + enum: [ 0, 1, 2, 3, 4, 5 ]
>
> Units? You should probably rename this adi,fifo-depth-bits and list
> the valid values in bits.
units are bits;
will adapt this
>
> > +
> > + adi,eee-enabled:
> > + description: |
> > + Advertise EEE capabilities on power-up/init (default disabled)
> > + type: boolean
>
> It is not the PHY which decides this. The MAC indicates if it is EEE
> capable to phylib. phylib looks into the PHY registers to determine if
> the PHY supports EEE. phylib will then enable EEE
> advertisement. Please remove this, and ensure EEE is disabled by
> default.
ack;
will remove
>
> Andrew
^ permalink raw reply
* Re: [PATCH mlx5-next v1 1/3] IB/mlx5: Query ODP capabilities for DC
From: Leon Romanovsky @ 2019-08-06 7:02 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Jason Gunthorpe, dledford@redhat.com, Michael Guralnik,
Moni Shoua, netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <d3b21502d398fc3bf2cf38231ca84c1bb0386b17.camel@mellanox.com>
On Mon, Aug 05, 2019 at 06:23:04PM +0000, Saeed Mahameed wrote:
> On Sun, 2019-08-04 at 13:00 +0300, Leon Romanovsky wrote:
> > From: Michael Guralnik <michaelgur@mellanox.com>
> >
> > Set current capabilities of ODP for DC to max capabilities and cache
> > them in mlx5_ib.
> >
> > Signed-off-by: Michael Guralnik <michaelgur@mellanox.com>
> > Reviewed-by: Moni Shoua <monis@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > ---
> > drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 +
> > drivers/infiniband/hw/mlx5/odp.c | 18
> > ++++++++++++++++++
> > drivers/net/ethernet/mellanox/mlx5/core/main.c | 6 ++++++
> > include/linux/mlx5/mlx5_ifc.h | 4 +++-
>
> Please avoid cross tree changes when you can..
> Here you do can avoid it, so please separate to two stage patches,
> mlx5_ifc and core, then mlx5_ib.
>
>
> > 4 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > index cb41a7e6255a..f99c71b3c876 100644
> > --- a/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > @@ -967,6 +967,7 @@ struct mlx5_ib_dev {
> > struct mutex slow_path_mutex;
> > int fill_delay;
> > struct ib_odp_caps odp_caps;
> > + uint32_t dc_odp_caps;
> > u64 odp_max_size;
> > struct mlx5_ib_pf_eq odp_pf_eq;
> >
> > diff --git a/drivers/infiniband/hw/mlx5/odp.c
> > b/drivers/infiniband/hw/mlx5/odp.c
> > index b0c5de39d186..5e87a5e25574 100644
> > --- a/drivers/infiniband/hw/mlx5/odp.c
> > +++ b/drivers/infiniband/hw/mlx5/odp.c
> > @@ -353,6 +353,24 @@ void mlx5_ib_internal_fill_odp_caps(struct
> > mlx5_ib_dev *dev)
> > if (MLX5_CAP_ODP(dev->mdev, xrc_odp_caps.srq_receive))
> > caps->per_transport_caps.xrc_odp_caps |=
> > IB_ODP_SUPPORT_SRQ_RECV;
> >
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.send))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_SEND;
> > +
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.receive))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_RECV;
> > +
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.write))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_WRITE;
> > +
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.read))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_READ;
> > +
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.atomic))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_ATOMIC;
> > +
> > + if (MLX5_CAP_ODP(dev->mdev, dc_odp_caps.srq_receive))
> > + dev->dc_odp_caps |= IB_ODP_SUPPORT_SRQ_RECV;
> > +
> > if (MLX5_CAP_GEN(dev->mdev, fixed_buffer_size) &&
> > MLX5_CAP_GEN(dev->mdev, null_mkey) &&
> > MLX5_CAP_GEN(dev->mdev, umr_extended_translation_offset))
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > index b15b27a497fc..3995fc6d4d34 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
> > @@ -495,6 +495,12 @@ static int handle_hca_cap_odp(struct
> > mlx5_core_dev *dev)
> > ODP_CAP_SET_MAX(dev, xrc_odp_caps.write);
> > ODP_CAP_SET_MAX(dev, xrc_odp_caps.read);
> > ODP_CAP_SET_MAX(dev, xrc_odp_caps.atomic);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.srq_receive);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.send);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.receive);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.write);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.read);
> > + ODP_CAP_SET_MAX(dev, dc_odp_caps.atomic);
> >
> > if (do_set)
> > err = set_caps(dev, set_ctx, set_sz,
> > diff --git a/include/linux/mlx5/mlx5_ifc.h
> > b/include/linux/mlx5/mlx5_ifc.h
> > index ec571fd7fcf8..5eae8d734435 100644
> > --- a/include/linux/mlx5/mlx5_ifc.h
> > +++ b/include/linux/mlx5/mlx5_ifc.h
> > @@ -944,7 +944,9 @@ struct mlx5_ifc_odp_cap_bits {
> >
> > struct mlx5_ifc_odp_per_transport_service_cap_bits
> > xrc_odp_caps;
> >
> > - u8 reserved_at_100[0x700];
> > + struct mlx5_ifc_odp_per_transport_service_cap_bits dc_odp_caps;
> > +
> > + u8 reserved_at_100[0x6E0];
>
> reserved_at_100 should move 20 bit forward. i.e reserved_at_120
Thanks for pointing it, I'm sending new version now.
>
>
^ permalink raw reply
* Re: [PATCH v2] net/mlx5e: Use refcount_t for refcount
From: Leon Romanovsky @ 2019-08-06 6:59 UTC (permalink / raw)
To: Saeed Mahameed
Cc: hslester96@gmail.com, davem@davemloft.net, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b19b7cd49d373cc51d3e745a6444b27166b88304.camel@mellanox.com>
On Mon, Aug 05, 2019 at 08:06:36PM +0000, Saeed Mahameed wrote:
> On Mon, 2019-08-05 at 14:55 +0800, Chuhong Yuan wrote:
> > On Mon, Aug 5, 2019 at 2:13 PM Leon Romanovsky <leon@kernel.org>
> > wrote:
> > > On Sun, Aug 04, 2019 at 10:44:47PM +0800, Chuhong Yuan wrote:
> > > > On Sun, Aug 4, 2019 at 8:59 PM Leon Romanovsky <leon@kernel.org>
> > > > wrote:
> > > > > On Sat, Aug 03, 2019 at 12:48:28AM +0800, Chuhong Yuan wrote:
> > > > > > refcount_t is better for reference counters since its
> > > > > > implementation can prevent overflows.
> > > > > > So convert atomic_t ref counters to refcount_t.
> > > > >
> > > > > I'm not thrilled to see those automatic conversion patches,
> > > > > especially
> > > > > for flows which can't overflow. There is nothing wrong in using
> > > > > atomic_t
> > > > > type of variable, do you have in mind flow which will cause to
> > > > > overflow?
> > > > >
> > > > > Thanks
> > > >
> > > > I have to say that these patches are not done automatically...
> > > > Only the detection of problems is done by a script.
> > > > All conversions are done manually.
> > >
> > > Even worse, you need to audit usage of atomic_t and replace there
> > > it can overflow.
> > >
> > > > I am not sure whether the flow can cause an overflow.
> > >
> > > It can't.
> > >
> > > > But I think it is hard to ensure that a data path is impossible
> > > > to have problems in any cases including being attacked.
> > >
> > > It is not data path, and I doubt that such conversion will be
> > > allowed
> > > in data paths without proving that no performance regression is
> > > introduced.
> > > > So I think it is better to do this minor revision to prevent
> > > > potential risk, just like we have done in mlx5/core/cq.c.
> > >
> > > mlx5/core/cq.c is a different beast, refcount there means actual
> > > users
> > > of CQ which are limited in SW, so in theory, they have potential
> > > to be overflown.
> > >
> > > It is not the case here, there your are adding new port.
> > > There is nothing wrong with atomic_t.
> > >
> >
> > Thanks for your explanation!
> > I will pay attention to this point in similar cases.
> > But it seems that the semantic of refcount is not always as clear as
> > here...
> >
>
> Semantically speaking, there is nothing wrong with moving to refcount_t
> in the case of vxlan ports.. it also seems more accurate and will
> provide the type protection, even if it is not necessary. Please let me
> know what is the verdict here, i can apply this patch to net-next-mlx5.
There is no verdict here, it is up to you., if you like code churn, go
for it.
Thanks
>
> Thanks,
> Saeed.
^ permalink raw reply
* [PATCH net-next v2 1/1] qed: Add new ethtool supported port types based on media.
From: Rahul Verma @ 2019-08-06 6:59 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
Supported ports in ethtool <eth1> are displayed based on media type.
For media type fibre and twinaxial, port type is "FIBRE". Media type
Base-T is "TP" and media KR is "Backplane".
V1->V2:
Corrected the subject.
Signed-off-by: Rahul Verma <rahulv@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 3 ++-
include/linux/qed/qed_if.h | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..e5ac8bd 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1688,6 +1688,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
switch (media_type) {
case MEDIA_DA_TWINAX:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
/* For DAC media multiple speed capabilities are supported*/
@@ -1707,6 +1708,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
*if_capability |= QED_LM_100000baseCR4_Full_BIT;
break;
case MEDIA_BASE_T:
+ *if_capability |= QED_LM_TP_BIT;
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_EXT_PHY) {
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
@@ -1718,6 +1720,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
}
}
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_MODULE) {
+ *if_capability |= QED_LM_FIBRE_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_1000BASET)
*if_capability |= QED_LM_1000baseT_Full_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_10G_BASET)
@@ -1728,6 +1731,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
case MEDIA_SFPP_10G_FIBER:
case MEDIA_XFP_FIBER:
case MEDIA_MODULE_FIBER:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
if ((tcvr_type == ETH_TRANSCEIVER_TYPE_1G_LX) ||
@@ -1770,6 +1774,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
break;
case MEDIA_KR:
+ *if_capability |= QED_LM_Backplane_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
if (capability &
@@ -1821,7 +1826,6 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->link_up = true;
/* TODO - at the moment assume supported and advertised speed equal */
- if_link->supported_caps = QED_LM_FIBRE_BIT;
if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index e85f9fe..abcee47 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -424,12 +424,13 @@ struct qede_link_mode_mapping {
};
static const struct qede_link_mode_mapping qed_lm_map[] = {
+ {QED_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT},
{QED_LM_Autoneg_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT},
{QED_LM_Asym_Pause_BIT, ETHTOOL_LINK_MODE_Asym_Pause_BIT},
{QED_LM_Pause_BIT, ETHTOOL_LINK_MODE_Pause_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseT_Full_BIT, ETHTOOL_LINK_MODE_10000baseT_Full_BIT},
- {QED_LM_2500baseX_Full_BIT, ETHTOOL_LINK_MODE_2500baseX_Full_BIT},
+ {QED_LM_TP_BIT, ETHTOOL_LINK_MODE_TP_BIT},
{QED_LM_Backplane_BIT, ETHTOOL_LINK_MODE_Backplane_BIT},
{QED_LM_1000baseKX_Full_BIT, ETHTOOL_LINK_MODE_1000baseKX_Full_BIT},
{QED_LM_10000baseKX4_Full_BIT, ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT},
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..2302136 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -689,7 +689,7 @@ enum qed_link_mode_bits {
QED_LM_40000baseLR4_Full_BIT = BIT(9),
QED_LM_50000baseKR2_Full_BIT = BIT(10),
QED_LM_100000baseKR4_Full_BIT = BIT(11),
- QED_LM_2500baseX_Full_BIT = BIT(12),
+ QED_LM_TP_BIT = BIT(12),
QED_LM_Backplane_BIT = BIT(13),
QED_LM_1000baseKX_Full_BIT = BIT(14),
QED_LM_10000baseKX4_Full_BIT = BIT(15),
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 16/16] dt-bindings: net: add bindings for ADIN PHY driver
From: Ardelean, Alexandru @ 2019-08-06 6:57 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805142754.GL24275@lunn.ch>
On Mon, 2019-08-05 at 16:27 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:53PM +0300, Alexandru Ardelean wrote:
> > This change adds bindings for the Analog Devices ADIN PHY driver, detailing
> > all the properties implemented by the driver.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > .../devicetree/bindings/net/adi,adin.yaml | 93 +++++++++++++++++++
> > MAINTAINERS | 2 +
> > include/dt-bindings/net/adin.h | 26 ++++++
> > 3 files changed, 121 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/adi,adin.yaml
> > create mode 100644 include/dt-bindings/net/adin.h
> >
> > diff --git a/Documentation/devicetree/bindings/net/adi,adin.yaml
> > b/Documentation/devicetree/bindings/net/adi,adin.yaml
> > new file mode 100644
> > index 000000000000..fcf884bb86f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/adi,adin.yaml
> > @@ -0,0 +1,93 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/adi,adin.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Analog Devices ADIN1200/ADIN1300 PHY
> > +
> > +maintainers:
> > + - Alexandru Ardelean <alexandru.ardelean@analog.com>
> > +
> > +description: |
> > + Bindings for Analog Devices Industrial Ethernet PHYsphy
> > +
> > +properties:
> > + compatible:
> > + description: |
> > + Compatible list, may contain "ethernet-phy-ieee802.3-c45" in which case
> > + Clause 45 will be used to access device management registers. If
> > + unspecified, Clause 22 will be used. Use this only when MDIO supports
> > + Clause 45 access, but there is no other way to determine this.
> > + enum:
> > + - ethernet-phy-ieee802.3-c45
>
> It is valid to list ethernet-phy-ieee802.3-c22, it is just not
> required. So maybe you should list it here to keep the DT validater happy?
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next] rdma: Add driver QP type string
From: Leon Romanovsky @ 2019-08-06 6:54 UTC (permalink / raw)
To: Gal Pressman; +Cc: David Ahern, Stephen Hemminger, netdev, linux-rdma
In-Reply-To: <d156ece6-79bf-f9a4-8b79-a5abf738476d@amazon.com>
On Tue, Aug 06, 2019 at 09:41:37AM +0300, Gal Pressman wrote:
> On 05/08/2019 22:08, David Ahern wrote:
> > On 8/4/19 2:07 AM, Gal Pressman wrote:
> >> RDMA resource tracker now tracks driver QPs as well, add driver QP type
> >> string to qp_types_to_str function.
> >
> > "now" means which kernel release? Leon: should this be in master or -next?
>
> Now means the patch is merged to RDMA's for-rc branch (5.3).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/infiniband?id=52e0a118a20308dd6aa531e20a5ab5907d2264c8
David,
I think that it is better to apply this patch to iproute2-rc just
to be on the same page with kernel patch.
Thanks
^ permalink raw reply
* Re: [PATCH 14/16] net: phy: adin: make sure down-speed auto-neg is enabled
From: Ardelean, Alexandru @ 2019-08-06 6:53 UTC (permalink / raw)
To: devicetree@vger.kernel.org, hkallweit1@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: f.fainelli@gmail.com, davem@davemloft.net, mark.rutland@arm.com,
robh+dt@kernel.org, andrew@lunn.ch
In-Reply-To: <baac3842-bd9c-75af-83e3-9e89def1c429@gmail.com>
On Tue, 2019-08-06 at 07:52 +0200, Heiner Kallweit wrote:
> [External]
>
> On 05.08.2019 18:54, Alexandru Ardelean wrote:
> > Down-speed auto-negotiation may not always be enabled, in which case the
> > PHY won't down-shift to 100 or 10 during auto-negotiation.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index 86848444bd98..a1f3456a8504 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -32,6 +32,13 @@
> > #define ADIN1300_NRG_PD_TX_EN BIT(2)
> > #define ADIN1300_NRG_PD_STATUS BIT(1)
> >
> > +#define ADIN1300_PHY_CTRL2 0x0016
> > +#define ADIN1300_DOWNSPEED_AN_100_EN BIT(11)
> > +#define ADIN1300_DOWNSPEED_AN_10_EN BIT(10)
> > +#define ADIN1300_GROUP_MDIO_EN BIT(6)
> > +#define ADIN1300_DOWNSPEEDS_EN \
> > + (ADIN1300_DOWNSPEED_AN_100_EN | ADIN1300_DOWNSPEED_AN_10_EN)
> > +
> > #define ADIN1300_INT_MASK_REG 0x0018
> > #define ADIN1300_INT_MDIO_SYNC_EN BIT(9)
> > #define ADIN1300_INT_ANEG_STAT_CHNG_EN BIT(8)
> > @@ -425,6 +432,22 @@ static int adin_config_mdix(struct phy_device *phydev)
> > return phy_write(phydev, ADIN1300_PHY_CTRL1, reg);
> > }
> >
> > +static int adin_config_downspeeds(struct phy_device *phydev)
> > +{
> > + int reg;
> > +
> > + reg = phy_read(phydev, ADIN1300_PHY_CTRL2);
> > + if (reg < 0)
> > + return reg;
> > +
> > + if ((reg & ADIN1300_DOWNSPEEDS_EN) == ADIN1300_DOWNSPEEDS_EN)
> > + return 0;
> > +
> > + reg |= ADIN1300_DOWNSPEEDS_EN;
> > +
> > + return phy_write(phydev, ADIN1300_PHY_CTRL2, reg);
>
> Using phy_set_bits() would be easier.
ack;
missed this;
thanks
>
> > +}
> > +
> > static int adin_config_aneg(struct phy_device *phydev)
> > {
> > int ret;
> > @@ -433,6 +456,10 @@ static int adin_config_aneg(struct phy_device *phydev)
> > if (ret)
> > return ret;
> >
> > + ret = adin_config_downspeeds(phydev);
> > + if (ret < 0)
> > + return ret;
> > +
> > return genphy_config_aneg(phydev);
> > }
> >
> >
^ permalink raw reply
* Re: [PATCH 14/16] net: phy: adin: make sure down-speed auto-neg is enabled
From: Ardelean, Alexandru @ 2019-08-06 6:53 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805152214.GS24275@lunn.ch>
On Mon, 2019-08-05 at 17:22 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:51PM +0300, Alexandru Ardelean wrote:
> > Down-speed auto-negotiation may not always be enabled, in which case the
> > PHY won't down-shift to 100 or 10 during auto-negotiation.
>
> Please look at how the marvell driver enables and configures this
> feature. Ideally we want all PHY drivers to use the same configuration
> API for features like this.
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH 12/16] net: phy: adin: read EEE setting from device-tree
From: Ardelean, Alexandru @ 2019-08-06 6:52 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805151909.GR24275@lunn.ch>
On Mon, 2019-08-05 at 17:19 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:49PM +0300, Alexandru Ardelean wrote:
> > By default, EEE is not advertised on system init. This change allows the
> > user to specify a device property to enable EEE advertisements when the PHY
> > initializes.
>
> This patch is not required. If EEE is not being advertised when it
> should, it means there is a MAC driver bug.
ack;
same thing about PHY specifics ignoring MAC specifics
thanks
>
> Andrew
^ permalink raw reply
* Re: [PATCH 11/16] net: phy: adin: PHY reset mechanisms
From: Ardelean, Alexandru @ 2019-08-06 6:50 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805151500.GP24275@lunn.ch>
On Mon, 2019-08-05 at 17:15 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:48PM +0300, Alexandru Ardelean wrote:
> > The ADIN PHYs supports 4 types of reset:
> > 1. The standard PHY reset via BMCR_RESET bit in MII_BMCR reg
> > 2. Reset via GPIO
> > 3. Reset via reg GeSftRst (0xff0c) & reload previous pin configs
> > 4. Reset via reg GeSftRst (0xff0c) & request new pin configs
> >
> > Resets 2 & 4 are almost identical, with the exception that the crystal
> > oscillator is available during reset for 2.
> >
> > Resetting via GeSftRst or via GPIO is useful when doing a warm reboot. If
> > doing various settings via phytool or ethtool, the sub-system registers
> > don't reset just via BMCR_RESET.
> >
> > This change implements resetting the entire PHY subsystem during probe.
> > During PHY HW init (phy_hw_init() logic) the PHY core regs will be reset
> > again via BMCR_RESET. This will also need to happen during a PM resume.
>
> phylib already has support for GPIO reset. So if possible, you should
> not repeat that code here.
>
> What is the difference between a GPIO reset, and a GPIO reset followed
> by a subsystem soft reset?
there shouldn't be any difference;
it's just 2 consecutive resets;
i'll take a closer look at phylib's GPIO reset and see
>
> Andrew
^ permalink raw reply
* Re: [PATCH 10/16] net: phy: adin: add EEE translation layer for Clause 22
From: Ardelean, Alexandru @ 2019-08-06 6:47 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805221150.GE25700@lunn.ch>
On Tue, 2019-08-06 at 00:11 +0200, Andrew Lunn wrote:
> [External]
>
> > +static int adin_cl22_to_adin_reg(int devad, u16 cl22_regnum)
> > +{
> > + struct clause22_mmd_map *m;
> > + int i;
> > +
> > + if (devad == MDIO_MMD_VEND1)
> > + return cl22_regnum;
> > +
> > + for (i = 0; i < ARRAY_SIZE(clause22_mmd_map); i++) {
> > + m = &clause22_mmd_map[i];
> > + if (m->devad == devad && m->cl22_regnum == cl22_regnum)
> > + return m->adin_regnum;
> > + }
> > +
> > + pr_err("No translation available for devad: %d reg: %04x\n",
> > + devad, cl22_regnum);
>
> phydev_err().
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH 06/16] net: phy: adin: support PHY mode converters
From: Ardelean, Alexandru @ 2019-08-06 6:47 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805145105.GN24275@lunn.ch>
On Mon, 2019-08-05 at 16:51 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:43PM +0300, Alexandru Ardelean wrote:
> > Sometimes, the connection between a MAC and PHY is done via a
> > mode/interface converter. An example is a GMII-to-RGMII converter, which
> > would mean that the MAC operates in GMII mode while the PHY operates in
> > RGMII. In this case there is a discrepancy between what the MAC expects &
> > what the PHY expects and both need to be configured in their respective
> > modes.
> >
> > Sometimes, this converter is specified via a board/system configuration (in
> > the device-tree for example). But, other times it can be left unspecified.
> > The use of these converters is common in boards that have FPGA on them.
> >
> > This patch also adds support for a `adi,phy-mode-internal` property that
> > can be used in these (implicit convert) cases. The internal PHY mode will
> > be used to specify the correct register settings for the PHY.
> >
> > `fwnode_handle` is used, since this property may be specified via ACPI as
> > well in other setups, but testing has been done in DT context.
>
> Looking at the patch, you seems to assume phy-mode is what the MAC is
> using? That seems rather odd, given the name. It seems like a better
> solution would be to add a mac-mode, which the MAC uses to configure
> its side of the link. The MAC driver would then implement this
> property.
>
actually, that's a pretty good idea;
i guess i was narrow-minded when writing the driver, and got stuck on phy specifics, and forgot about the MAC-side;
[ i also catch these design elements when reviewing, but i also seem to miss them when writing stuff sometimes ]
thanks
> I don't see a need for this. phy-mode indicates what the PHY should
> use. End of story.
>
> Andrew
^ permalink raw reply
* Re: [PATCH 05/16] net: phy: adin: configure RGMII/RMII/MII modes on config
From: Ardelean, Alexandru @ 2019-08-06 6:43 UTC (permalink / raw)
To: andrew@lunn.ch
Cc: davem@davemloft.net, hkallweit1@gmail.com,
devicetree@vger.kernel.org, mark.rutland@arm.com,
linux-kernel@vger.kernel.org, f.fainelli@gmail.com,
netdev@vger.kernel.org, robh+dt@kernel.org
In-Reply-To: <20190805143935.GM24275@lunn.ch>
On Mon, 2019-08-05 at 16:39 +0200, Andrew Lunn wrote:
> [External]
>
> On Mon, Aug 05, 2019 at 07:54:42PM +0300, Alexandru Ardelean wrote:
> > The ADIN1300 chip supports RGMII, RMII & MII modes. Default (if
> > unconfigured) is RGMII.
> > This change adds support for configuring these modes via the device
> > registers.
> >
> > For RGMII with internal delays (modes RGMII_ID,RGMII_TXID, RGMII_RXID),
>
> It would be nice to add the missing space.
>
> > the default delay is 2 ns. This can be configurable and will be done in
> > a subsequent change.
> >
> > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > ---
> > drivers/net/phy/adin.c | 79 +++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 78 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
> > index 3dd9fe50f4c8..dbdb8f60741c 100644
> > --- a/drivers/net/phy/adin.c
> > +++ b/drivers/net/phy/adin.c
> > @@ -33,14 +33,91 @@
> > ADIN1300_INT_HW_IRQ_EN)
> > #define ADIN1300_INT_STATUS_REG 0x0019
> >
> > +#define ADIN1300_GE_RGMII_CFG_REG 0xff23
> > +#define ADIN1300_GE_RGMII_RXID_EN BIT(2)
> > +#define ADIN1300_GE_RGMII_TXID_EN BIT(1)
> > +#define ADIN1300_GE_RGMII_EN BIT(0)
> > +
> > +#define ADIN1300_GE_RMII_CFG_REG 0xff24
> > +#define ADIN1300_GE_RMII_EN BIT(0)
> > +
> > +static int adin_config_rgmii_mode(struct phy_device *phydev,
> > + phy_interface_t intf)
> > +{
> > + int reg;
> > +
> > + reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_GE_RGMII_CFG_REG);
> > + if (reg < 0)
> > + return reg;
> > +
> > + if (!phy_interface_mode_is_rgmii(intf)) {
> > + reg &= ~ADIN1300_GE_RGMII_EN;
> > + goto write;
> > + }
> > +
> > + reg |= ADIN1300_GE_RGMII_EN;
> > +
> > + if (intf == PHY_INTERFACE_MODE_RGMII_ID ||
> > + intf == PHY_INTERFACE_MODE_RGMII_RXID) {
> > + reg |= ADIN1300_GE_RGMII_RXID_EN;
> > + } else {
> > + reg &= ~ADIN1300_GE_RGMII_RXID_EN;
> > + }
> > +
> > + if (intf == PHY_INTERFACE_MODE_RGMII_ID ||
> > + intf == PHY_INTERFACE_MODE_RGMII_TXID) {
> > + reg |= ADIN1300_GE_RGMII_TXID_EN;
> > + } else {
> > + reg &= ~ADIN1300_GE_RGMII_TXID_EN;
> > + }
>
> Nice. Often driver writers forget to clear the delay, they only set
> it. Not so here.
>
> However, is checkpatch happy with this? Each half of the if/else is a
> single statement, so the {} are not needed.
it did not complain;
this whole series is checkpatch friendly [with the version of checkpatch in net-next]
i think it complained about un-balanced if-block; something like:
```
if () {
} else
single-statement
```
but checkpatch is also a moving target;
so ¯\_(ツ)_/¯
>
> > +
> > +write:
> > + return phy_write_mmd(phydev, MDIO_MMD_VEND1,
> > + ADIN1300_GE_RGMII_CFG_REG, reg);
> > +}
> > +
> > +static int adin_config_rmii_mode(struct phy_device *phydev,
> > + phy_interface_t intf)
> > +{
> > + int reg;
> > +
> > + reg = phy_read_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_GE_RMII_CFG_REG);
> > + if (reg < 0)
> > + return reg;
> > +
> > + if (intf != PHY_INTERFACE_MODE_RMII) {
> > + reg &= ~ADIN1300_GE_RMII_EN;
> > + goto write;
>
> goto? Really?
yep;
personally, i used to not like it all that much up until a few years, but sometimes it feels it can help with creating
cleaner patches in certain contexts;
i'll re-spin without it;
>
> > + }
> > +
> > + reg |= ADIN1300_GE_RMII_EN;
> > +
> > +write:
> > + return phy_write_mmd(phydev, MDIO_MMD_VEND1,
> > + ADIN1300_GE_RMII_CFG_REG, reg);
> > +}
> > +
> > static int adin_config_init(struct phy_device *phydev)
> > {
> > - int rc;
> > + phy_interface_t interface, rc;
>
> genphy_config_init() does not return a phy_interface_t!
good point;
will check;
>
> >
> > rc = genphy_config_init(phydev);
> > if (rc < 0)
> > return rc;
> >
> > + interface = phydev->interface;
> > +
> > + rc = adin_config_rgmii_mode(phydev, interface);
> > + if (rc < 0)
> > + return rc;
> > +
> > + rc = adin_config_rmii_mode(phydev, interface);
> > + if (rc < 0)
> > + return rc;
> > +
> > + dev_info(&phydev->mdio.dev, "PHY is using mode '%s'\n",
> > + phy_modes(phydev->interface));
>
> phydev_dbg(), or not at all.
ack
>
> Andrew
^ permalink raw reply
* Re: [PATCH iproute2-next] rdma: Add driver QP type string
From: Gal Pressman @ 2019-08-06 6:41 UTC (permalink / raw)
To: David Ahern, Stephen Hemminger; +Cc: netdev, linux-rdma, Leon Romanovsky
In-Reply-To: <fd623a4e-d076-3eea-2d1e-7702812b0dfc@gmail.com>
On 05/08/2019 22:08, David Ahern wrote:
> On 8/4/19 2:07 AM, Gal Pressman wrote:
>> RDMA resource tracker now tracks driver QPs as well, add driver QP type
>> string to qp_types_to_str function.
>
> "now" means which kernel release? Leon: should this be in master or -next?
Now means the patch is merged to RDMA's for-rc branch (5.3).
^ 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