- 24 Nov, 2018 40 commits
-
-
Petr Machata authored
Drop switchdev_ops.switchdev_port_obj_add and _del. Drop the uses of this field from all clients, which were migrated to use switchdev notification in the previous patches. Add a new function switchdev_port_obj_notify() that sends the switchdev notifications SWITCHDEV_PORT_OBJ_ADD and _DEL. Update switchdev_port_obj_del_now() to dispatch to this new function. Drop __switchdev_port_obj_add() and update switchdev_port_obj_add() likewise. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. Dispatch the new events to ocelot_port_obj_add() resp. _del() to maintain the same behavior that the switchdev operation based code currently has. Pass through switchdev_handle_port_obj_add() / _del() to handle the recursive descend, because Ocelot supports LAG uppers. Register to the new switchdev blocking notifier chain to get the new events when they start getting distributed. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking notifier chain. Dispatch to mlxsw_sp_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Defer to switchdev_handle_port_obj_add() / _del() to handle the recursive descend, because mlxsw supports a number of upper types. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
After the transition from switchdev operations to notifier chain (which will take place in following patches), the onus is on the driver to find its own devices below possible layer of LAG or other uppers. The logic to do so is fairly repetitive: each driver is looking for its own devices among the lowers of the notified device. For those that it finds, it calls a handler. To indicate that the event was handled, struct switchdev_notifier_port_obj_info.handled is set. The differences lie only in what constitutes an "own" device and what handler to call. Therefore abstract this logic into two helpers, switchdev_handle_port_obj_add() and switchdev_handle_port_obj_del(). If a driver only supports physical ports under a bridge device, it will simply avoid this layer of indirection. One area where this helper diverges from the current switchdev behavior is the case of mixed lowers, some of which are switchdev ports and some of which are not. Previously, such scenario would fail with -EOPNOTSUPP. The helper could do that for lowers for which the passed-in predicate doesn't hold. That would however break the case that switchdev ports from several different drivers are stashed under one master, a scenario that switchdev currently happily supports. Therefore tolerate any and all unknown netdevices, whether they are backed by a switchdev driver or not. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. ethsw currently doesn't support any uppers other than bridge. SWITCHDEV_OBJ_ID_HOST_MDB and _PORT_MDB objects are always notified on the bridge port device. Thus the only case that a stacked device could be validly referenced by port object notifications are bridge notifications for VLAN objects added to the bridge itself. But the driver explicitly rejects such notifications in port_vlans_add(). It is therefore safe to assume that the only interesting case is that the notification is on a front-panel port netdevice. To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking notifier chain. Dispatch to swdev_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
ethsw currently uses an open-coded comparison of netdev_ops to determine whether whether a device represents a front panel port. Wrap this into a named function to simplify reuse. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. DSA currently doesn't support any other uppers than bridge. SWITCHDEV_OBJ_ID_HOST_MDB and _PORT_MDB objects are always notified on the bridge port device. Thus the only case that a stacked device could be validly referenced by port object notifications are bridge notifications for VLAN objects added to the bridge itself. But the driver explicitly rejects such notifications in dsa_port_vlan_add(). It is therefore safe to assume that the only interesting case is that the notification is on a front-panel port netdevice. Therefore keep the filtering by dsa_slave_dev_check() in place. To handle SWITCHDEV_PORT_OBJ_ADD and _DEL, subscribe to the blocking notifier chain. Dispatch to rocker_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
Following patches will change the way of distributing port object changes from a switchdev operation to a switchdev notifier. The switchdev code currently recursively descends through layers of lower devices, eventually calling the op on a front-panel port device. The notifier will instead be sent referencing the bridge port device, which may be a stacking device that's one of front-panel ports uppers, or a completely unrelated device. rocker currently doesn't support any uppers other than bridge. Thus the only case that a stacked device could be validly referenced by port object notifications are bridge notifications for VLAN objects added to the bridge itself. But the driver explicitly rejects such notifications in rocker_world_port_obj_vlan_add(). It is therefore safe to assume that the only interesting case is that the notification is on a front-panel port netdevice. Subscribe to the blocking notifier chain. In the handler, filter out notifications on any foreign netdevices. Dispatch the new notifiers to rocker_port_obj_add() resp. _del() to maintain the behavior that the switchdev operation based code currently has. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
An offloading driver may need to have access to switchdev events on ports that aren't directly under its control. An example is a VXLAN port attached to a bridge offloaded by a driver. The driver needs to know about VLANs configured on the VXLAN device. However the VXLAN device isn't stashed between the bridge and a front-panel-port device (such as is the case e.g. for LAG devices), so the usual switchdev ops don't reach the driver. VXLAN is likely not the only device type like this: in theory any L2 tunnel device that needs offloading will prompt requirement of this sort. This falsifies the assumption that only the lower devices of a front panel port need to be notified to achieve flawless offloading. A way to fix this is to give up the notion of port object addition / deletion as a switchdev operation, which assumes somewhat tight coupling between the message producer and consumer. And instead send the message over a notifier chain. To that end, introduce two new switchdev notifier types, SWITCHDEV_PORT_OBJ_ADD and SWITCHDEV_PORT_OBJ_DEL. These notifier types communicate the same event as the corresponding switchdev op, except in a form of a notification. struct switchdev_notifier_port_obj_info was added to carry the fields that the switchdev op carries. An additional field, handled, will be used to communicate back to switchdev that the event has reached an interested party, which will be important for the two-phase commit. The two switchdev operations themselves are kept in place. Following patches first convert individual clients to the notifier protocol, and only then are the operations removed. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
In general one can't assume that a switchdev notifier is called in a non-atomic context, and correspondingly, the switchdev notifier chain is an atomic one. However, port object addition and deletion messages are delivered from a process context. Even the MDB addition messages, whose delivery is scheduled from atomic context, are queued and the delivery itself takes place in blocking context. For VLAN messages in particular, keeping the blocking nature is important for error reporting. Therefore introduce a blocking notifier chain and related service functions to distribute the notifications for which a blocking context can be assumed. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Petr Machata authored
The two macros SWITCHDEV_OBJ_PORT_VLAN() and SWITCHDEV_OBJ_PORT_MDB() expand to a container_of() call, yielding an appropriate container of their sole argument. However, due to a name collision, the first argument, i.e. the contained object pointer, is not the only one to get expanded. The third argument, which is a structure member name, and should be kept literal, gets expanded as well. The only safe way to use these two macros is therefore to name the local variable passed to them "obj". To fix this, rename the sole argument of the two macros from "obj" (which collides with the member name) to "OBJ". Additionally, instead of passing "OBJ" to container_of() verbatim, parenthesize it, so that a comma in the passed-in expression doesn't pollute the container_of() invocation. Signed-off-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: some functional improvements This series includes a few functional improvements. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Replace macro TX_FRAGS_READY_FOR with function rtl_tx_slots_avail to make code cleaner and type-safe. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Use napi_consume_skb() where possible to profit from bulk free infrastructure. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
For the GMII chip versions we set the version number which was set already. This can be simplified. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Even the chip versions within a family have so many differences that using a default chip version doesn't really make sense. Instead of leaving a best case flaky network connectivity, bail out and report the unknown chip version. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Remove ancient GCC bug workaround in a second place and factor out rtl_8169_get_txd_opts1. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Salil Mehta says: ==================== net: hns3: Adds support of debugfs to HNS3 driver This patchset adds support of debugfs to the HNS3 driver. Support has been added to query info related to below items: 1. Queue related ("echo queue info [queue no] > cmd") 2. Flow Director ("echo dump fd tcam > cmd") 3. TC config ("echo dump tc > cmd") 4. Transmit Module/Scheduler ("echo dump tm > cmd") 5. QoS pause ("echo dump qos pause cfg > cmd") 6. QoS buffer ("echo dump qos pri map > cmd") 7. QoS prio map ("echo dump qos buf cfg > cmd") NOTE: Above commands are *read-only* and are only intended to query the information from the SoC(and dump inside the kernel, for now) and in no way tries to perform write operations for the purpose of configuration etc. Change Log ---------- V1-->V2: * Addressed the comments provided by Jakub Kicinski. 1. Removed the .rej files mistakenly made part of Flow Director patch. Link: https://lkml.org/lkml/2018/11/20/249 2. Added command summary in the cover letter Link: https://lkml.org/lkml/2018/11/22/1 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
This patch prints qos buffer config information. debugfs command: echo dump qos buf cfg > cmd Sample Command: root@(none)# echo dump qos buf cfg > cmd hns3 0000:7d:00.0: dump qos buf cfg hns3 0000:7d:00.0: tx_packet_buf_tc_0: 0x1aa hns3 0000:7d:00.0: tx_packet_buf_tc_1: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_2: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_3: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_4: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_5: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_6: 0x0 hns3 0000:7d:00.0: tx_packet_buf_tc_7: 0x0 hns3 0000:7d:00.0: hns3 0000:7d:00.0: rx_packet_buf_tc_0: 0x130 hns3 0000:7d:00.0: rx_packet_buf_tc_1: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_2: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_3: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_4: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_5: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_6: 0x0 hns3 0000:7d:00.0: rx_packet_buf_tc_7: 0x0 hns3 0000:7d:00.0: rx_share_buf: 0x1e0e root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
This patch prints qos priority map information. debugfs command: echo dump qos pri map > cmd Sample Command: root@(none)# echo dump qos pri map > cmd hns3 0000:7d:00.0: dump qos pri map hns3 0000:7d:00.0: vlan_to_pri: 0x0 hns3 0000:7d:00.0: pri_0_to_tc: 0x0 hns3 0000:7d:00.0: pri_1_to_tc: 0x0 hns3 0000:7d:00.0: pri_2_to_tc: 0x0 hns3 0000:7d:00.0: pri_3_to_tc: 0x0 hns3 0000:7d:00.0: pri_4_to_tc: 0x0 hns3 0000:7d:00.0: pri_5_to_tc: 0x0 hns3 0000:7d:00.0: pri_6_to_tc: 0x0 hns3 0000:7d:00.0: pri_7_to_tc: 0x0 root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
This patch prints qos pause config information. debugfs command: echo dump qos pause cfg > cmd Sample Command: root@(none)# echo dump qos pause cfg > cmd hns3 0000:7d:00.0: dump qos pause cfg hns3 0000:7d:00.0: pause_trans_gap: 0xff hns3 0000:7d:00.0: pause_trans_time: 0xffff root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
This patch prints Transmit Module's Traffic sched related config information. debugfs command: echo dump tm > cmd Sample output: root@(none)# echo dump tm > cmd hns3 0000:7d:00.0: dump tm hns3 0000:7d:00.0: PG_TO_PRI gp_id: 0 hns3 0000:7d:00.0: PG_TO_PRI map: 0x1 hns3 0000:7d:00.0: QS_TO_PRI qs_id: 0 hns3 0000:7d:00.0: QS_TO_PRI priority: 0 hns3 0000:7d:00.0: QS_TO_PRI link_vld: 1 hns3 0000:7d:00.0: NQ_TO_QS nq_id: 0 hns3 0000:7d:00.0: NQ_TO_QS qset_id: 1024 hns3 0000:7d:00.0: PG pg_id: 0 hns3 0000:7d:00.0: PG dwrr: 100 hns3 0000:7d:00.0: QS qs_id: 0 hns3 0000:7d:00.0: QS dwrr: 100 hns3 0000:7d:00.0: PRI pri_id: 0 hns3 0000:7d:00.0: PRI dwrr: 100 hns3 0000:7d:00.0: PRI_C pri_id: 0 hns3 0000:7d:00.0: PRI_C pri_shapping: 0x2850000 hns3 0000:7d:00.0: PRI_P pri_id: 0 hns3 0000:7d:00.0: PRI_P pri_shapping: 0x2850796 hns3 0000:7d:00.0: PG_C pg_id: 0 hns3 0000:7d:00.0: PG_C pg_shapping: 0x2850000 hns3 0000:7d:00.0: PG_P pg_id: 0 hns3 0000:7d:00.0: PG_P pg_shapping: 0x2850496 hns3 0000:7d:00.0: PORT port_shapping: 0x2850296 hns3 0000:7d:00.0: PG_SCH pg_id: 0 hns3 0000:7d:00.0: PRI_SCH pg_id: 0 hns3 0000:7d:00.0: QS_SCH pg_id: 0 hns3 0000:7d:00.0: BP_TO_QSET pg_id: 0 hns3 0000:7d:00.0: BP_TO_QSET pg_shapping: 0x0 hns3 0000:7d:00.0: BP_TO_QSET qs_bit_map: 0x0 root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
This patch prints tc config information. debugfs command: echo dump tc > cmd Sample Output: root@(none)# echo dump tc > cmd hns3 0000:7d:00.0: weight_offset: 14 hns3 0000:7d:00.0: tc(0): no sp mode hns3 0000:7d:00.0: tc(1): no sp mode hns3 0000:7d:00.0: tc(2): no sp mode hns3 0000:7d:00.0: tc(3): no sp mode hns3 0000:7d:00.0: tc(4): no sp mode hns3 0000:7d:00.0: tc(5): no sp mode hns3 0000:7d:00.0: tc(6): no sp mode hns3 0000:7d:00.0: tc(7): no sp mode root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
All the Flow Director rules are stored in tcam blocks. For each bit of tcam entry, the match value depends on two input value(x, y). debugfs command: echo dump fd tcam > cmd Sample output: root@(none)# echo dump fd tcam > cmd hns3 0000:7d:00.0: read result tcam key x(31): hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 08000000 hns3 0000:7d:00.0: 00000600 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: read result tcam key y(31): hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: f7ff0000 hns3 0000:7d:00.0: 0000f900 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 00000000 hns3 0000:7d:00.0: 0000fff8 root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
Query the queue information of the current NIC such as BD size, queue header and tail pointer. This patch adds support for debugfs command: echo queue info 1 > cmd it can print queue config information... root@(none)# echo queue info 1 > cmd hns3 0000:7d:00.0: queue info hns3 0000:7d:00.0: RX(1) BASE ADD: 0x00000000ffb58000 hns3 0000:7d:00.0: RX(1) RING BD NUM: 127 hns3 0000:7d:00.0: RX(1) RING BD LEN: 2 hns3 0000:7d:00.0: RX(1) RING TAIL: 120 hns3 0000:7d:00.0: RX(1) RING HEAD: 0 hns3 0000:7d:00.0: RX(1) RING FBDNUM: 0 hns3 0000:7d:00.0: RX(1) RING PKTNUM: 0 hns3 0000:7d:00.0: TX(1) BASE ADD: 0x00000000fffd8000 hns3 0000:7d:00.0: TX(1) RING BD NUM: 127 hns3 0000:7d:00.0: TX(1) RING TC: 0 hns3 0000:7d:00.0: TX(1) RING TAIL: 2 hns3 0000:7d:00.0: TX(1) RING HEAD: 2 hns3 0000:7d:00.0: TX(1) RING FBDNUM: 0 hns3 0000:7d:00.0: TX(1) RING OFFSET: 0 hns3 0000:7d:00.0: TX(1) RING PKTNUM: 0 root@(none)# Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
liuzhongzhu authored
Add the debugfs framework to the driver and create a debugfs command interface for each device. example command: "echo queue info > cmd" Query the packet forwarding queue information. Signed-off-by: liuzhongzhu <liuzhongzhu@huawei.com> Signed-off-by: Salil Mehta <salil.mehta@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
ptp_clock_register never return NULL, so no need check this in cavium_ptp_probe. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Quentin Schulz authored
A more featureful support for VSC8574 was recently added to the Microsemi (mscc.c) driver. I checked that features supported in the Vitesse driver are also supported in the Microsemi driver. Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Linu Cherian says: ==================== octeontx2-af: CGX LMAC link bringup and cleanups Patch 1: Code cleanup Patch 2: Adds support for an unhandled hardware configuration Patch 3: Preparatory patch for enabling cgx lmac links Patch 4: Support for enabling cgx lmac links ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linu Cherian authored
- Added new CGX firmware interface API for sending link up/down commands - Do link up for cgx lmac ports by default at the time of CGX driver probe. Since cgx link up in driver probe affects the Linux boot time, linkup procedure is kept threaded using workqueues. For this, a new cgx API cgx_lmac_linkup_start has been added. Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linu Cherian authored
Added provision to unregister cgx event callbacks. This enables the exit path to ensure event callbacks are unregistered before workqueues get destroyed. Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linu Cherian authored
For this, cgx_id(struct cgx) definition has been changed to reflect cgx port id instead of device instance id. Now cgx_id can be directly used as channel offset for NPC configuration. Assumptions on contiguous cgx port ids has been removed from nix_calibrate_x2p as well. As a side effect, allocation of conversion tables that were based on cgx count are changed to cgx port id max value. Tables would return NULL for invalid cgx ports. Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Linu Cherian authored
* Do CGX init before NIX init This would add consistency in NIX code that depends on cgx ports * Few other misc cleanups - rvu_cgx_probe renamed as rvu_cgx_init for consistency - rvu_cgx_exit wrapper added to take care of the exit path - Added error check on cgx_lmac_event_handler_init - Minor cleanups in cgx.h related to tab alignment - Removed redundant ids from enum cgx_cmd_id Signed-off-by: Linu Cherian <lcherian@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
Pointer hwdev is being dereferenced when declaring hwif , however, later on hwdev is being null checked, hence we have dereference before null check error. Fix this by assigning hwif and pdef only once hwdev has been null checked. Detected by CoverityScan, CID#1485581 ("Dereference before null check") Fixes: 4a61abb1 ("net-next/hinic:add rx checksum offload for HiNIC") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ursula Braun says: ==================== net/smc: patches 2018-11-22 here are more patches for SMC: * patches 1-3 and 7 are cleanups without functional change * patches 4-6 and 8 are optimizations of existing code * patches 9 and 10 introduce and exploit LLC message DELETE RKEY ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Karsten Graul authored
When an rmb is no longer in use by a connection, unregister its rkey at the remote peer with an LLC DELETE RKEY message. With this change, unused buffers held in the buffer pool are no longer registered at the remote peer. They are registered before the buffer is actually used and unregistered when they are no longer used by a connection. Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Karsten Graul authored
Add the infrastructure to send LLC messages of type DELETE RKEY to unregister a shared memory region at the peer. Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Karsten Graul authored
When a send failed then don't start to wait for a response in smc_llc_do_confirm_rkey. Signed-off-by: Karsten Graul <kgraul@linux.ibm.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
For easier reading move the unlock of mutex smc_create_lgr_pending into smc_listen_work(), i.e. into the function the mutex has been locked. No functional change. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ursula Braun authored
After sending one of the initial LLC messages CONFIRM LINK or ADD LINK, there is already a wait for the LLC response. It does not make sense to wait another long time for a CLC DECLINE. Thus this patch introduces a shorter wait time for these cases. Signed-off-by: Ursula Braun <ubraun@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-