- 18 Oct, 2018 40 commits
-
-
Gustavo A. R. Silva authored
In case memory resources for *fw* were successfully allocated, release them before return. Addresses-Coverity-ID: 1473968 ("Resource leak") Fixes: 00d70d8e ("net: phy: mscc: add support for VSC8574 PHY") Reviewed-by:Quentin Schulz <quentin.schulz@bootlin.com> Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
Currently, the error handling for the call to function phy_read_paged() doesn't work because *reg_val* is of type u16 (16 bits, unsigned), which makes it impossible for it to hold a value less than 0. Fix this by changing the type of variable *reg_val* to int. Addresses-Coverity-ID: 1473970 ("Unsigned compared against 0") Fixes: 6a0bfbbe ("net: phy: mscc: migrate to phy_select/restore_page functions") Reviewed-by: -
Kyeongdon Kim authored
This fixes the "'hash' may be used uninitialized in this function" net/unix/af_unix.c:1041:20: warning: 'hash' may be used uninitialized in this function [-Wmaybe-uninitialized] addr->hash = hash ^ sk->sk_type; Signed-off-by:
Kyeongdon Kim <kyeongdon.kim@lge.com> Signed-off-by:
-
Marek Behún authored
This is a fix for the port_set_speed method for the Topaz family. Currently the same method is used as for the Peridot family, but this is wrong for the SERDES port. On Topaz, the SERDES port is port 5, not 9 and 10 as in Peridot. Moreover setting alt_bit on Topaz only makes sense for port 0 (for (differentiating 100mbps vs 200mbps). The SERDES port does not support more than 2500mbps, so alt_bit does not make any difference. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Signed-off-by:
-
David S. Miller authored
Sunil Goutham says: ==================== octeontx2-af: NPA and NIX blocks initialization This patchset is a continuation to earlier submitted patch series to add a new driver for Marvell's OcteonTX2 SOC's Resource virtualization unit (RVU) admin function driver. octeontx2-af: Add RVU Admin Function driver https://www.spinics.net/lists/netdev/msg528272.html This patch series adds logic for the following. - Modified register polling loop to use time_before(jiffies, timeout), as suggested by Arnd Bergmann. - Support to forward interface link status notifications sent by firmware to registered PFs mapped to a CGX::LMAC. - Support to set CGX LMAC in loopback mode, retrieve stats, configure DMAC filters at CGX level etc. - Network pool allocator (NPA) functional block initialization, admin queue support, NPALF aura/pool contexts memory allocation, init and deinit. - Network interface controller (NIX) functional block basic init, admin queue support, NIXLF RQ/CQ/SQ HW contexts memory allocation, init and deinit. ==================== Signed-off-by:
-
Geetha sowjanya authored
This patch adds support for a RVU PF/VF to disable all RQ/SQ/CQ contexts of a NIX LF via mbox. This will be used by PF/VF drivers upon teardown or while freeing up HW resources. A HW context which is not INIT'ed cannot be modified and a RVU PF/VF driver may or may not INIT all the RQ/SQ/CQ contexts. So a bitmap is introduced to keep track of enabled NIX RQ/SQ/CQ contexts, so that only enabled hw contexts are disabled upon LF teardown. Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Stanislaw Kardach <skardach@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
-
Sunil Goutham authored
Add support for a RVU PF/VF to submit instructions to NIX AQ via mbox. Instructions can be to init/write/read RQ/SQ/CQ/RSS contexts. In case of read, context will be returned as part of response to the mbox msg received. Signed-off-by:
-
Sunil Goutham authored
Allocate bitmaps and memory for PFVF mapping info for maintaining NIX transmit scheduler queues maintenance. PF/VF drivers will request for alloc, free e.t.c of Tx schedulers via mailbox. Signed-off-by:
-
Sunil Goutham authored
Config LSO formats for TSOv4 and TSOv6 offloads. These formats tell HW which fields in the TCP packet's headers have to be updated while performing segmentation offload. Also report PF/VF drivers the LSO format indices as part of response to NIX_LF_ALLOC mbox msg. These indices are used in SQE extension headers while framing SQE for pkt transmission with TSO offload. Signed-off-by:
-
Sunil Goutham authored
Upon receiving NIX_LF_ALLOC mbox message allocate memory for NIXLF's CQ, SQ, RQ, CINT, QINT and RSS HW contexts and configure respective base iova HW. Enable caching of contexts into NIX NDC. Return SQ buffer (SQB) size, this PF/VF MAC address etc info e.t.c to the mbox msg sender. Signed-off-by:
-
Sunil Goutham authored
Initialize NIX admin queue (AQ) i.e alloc memory for AQ instructions and for the results. All NIX LFs will submit instructions to AQ to init/write/read RQ/SQ/CQ/RSS contexts and in case of read, get context from result memory. Also before configuring/using NIX block calibrate X2P bus and check if NIX interfaces like CGX and LBK are in active and working state. Signed-off-by:
-
Geetha sowjanya authored
This patch adds support for a RVU PF/VF to disable all Aura/Pool contexts of a NPA LF via mbox. This will be used by PF/VF drivers upon teardown or while freeing up HW resources. A HW context which is not INIT'ed cannot be modified and a RVU PF/VF driver may or may not INIT all the Aura/Pool contexts. So a bitmap is introduced to keep track of enabled NPA Aura/Pool contexts, so that only enabled hw contexts are disabled upon LF teardown. Signed-off-by:
-
Sunil Goutham authored
Add support for a RVU PF/VF to submit instructions to NPA AQ via mbox. Instructions can be to init/write/read Aura/Pool/Qint contexts. In case of read, context will be returned as part of response to the mbox msg received. Signed-off-by:
-
Sunil Goutham authored
Upon receiving NPA_LF_ALLOC mbox message allocate memory for NPALF's aura, pool and qint contexts and configure the same to HW. Enable caching of contexts into NPA NDC. Return pool related info like stack size, num pointers per stack page e.t.c to the mbox msg sender. Signed-off-by:
-
Sunil Goutham authored
Initialize NPA admin queue (AQ) i.e alloc memory for AQ instructions and for the results. All NPA LFs will submit instructions to AQ to init/write/read Aura/Pool contexts and in case of read, get context from result memory. Added some common APIs for allocating memory for a queue and get IOVA in return, these APIs will be used by NIX AQ and for other purposes. Signed-off-by:
-
Geetha sowjanya authored
Add support to enable or disable internal loopback mode in CGX. New mbox IDs CGX_INTLBK_ENABLE/DISABLE added for this. Signed-off-by:
Linu Cherian <lcherian@marvell.com> Signed-off-by:
-
Linu Cherian authored
Upon receiving notification from firmware the CGX event handler in the AF driver gets the current link info such as status, speed, duplex etc from CGX driver and sends it across to PFs who have registered to receive such notifications. To support above - Mbox messaging support for sending msgs from AF to PF has been added. - Added mbox msgs so that PFs can register/unregister for link events. - Link notifications are sent to PF under two scenarioss. 1. When a asynchronous link change notification is received from firmware with notification flag turned on for that PF. 2. Upon notification turn on request, the current link status is send to the PF. Also added a new mailbox msg using which RVU PF/VF can retrieve their mapped CGX LMAC's current link info. Link info includes status, speed, duplex and lmac type. Signed-off-by: -
Vidhya Raman authored
This patch adds support for setting MAC address filters in CGX for PF interfaces. Also PF interfaces can be put in promiscuous mode. Dataplane PFs access this functionality using mailbox messages to the AF driver. Signed-off-by:
Vidhya Raman <vraman@marvell.com> Signed-off-by:
-
Christina Jacob authored
This patch adds support for a RVU PF/VF driver to retrieve it's mapped CGX LMAC Rx and Tx stats from AF via mbox. New mailbox msg is added is added. Signed-off-by:
Christina Jacob <cjacob@marvell.com> Signed-off-by:
-
Sunil Goutham authored
Added new mailbox msgs for RVU PF/VFs to request AF to enable/disable their mapped CGX::LMAC Rx & Tx. Signed-off-by:
-
Sunil Goutham authored
Instead of looping on a integer timeout, use time_before(jiffies), so that maximum poll time is capped. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Add VxLAN support This patchset adds support for VxLAN offload in the mlxsw driver. With regards to the forwarding plane, VxLAN support is composed from two main parts: Encapsulation and decapsulation. In the device, NVE encapsulation (and VxLAN in particular) takes place in the bridge. A packet can be encapsulated using VxLAN either because it hit an FDB entry that forwards it to the router with the IP of the remote VTEP or because it was flooded, in which case it is sent to a list of remote VTEPs (in addition to local ports). In either case, the VNI is derived from the filtering identifier (FID) the packet was classified to at ingress and the underlay source IP is taken from a device global configuration. VxLAN decapsulation takes place in the underlay router, where packets that hit a local route that corresponds to the source IP of the local VTEP are decapsulated and injected to the bridge. The packets are classified to a FID based on the VNI they came with. The first six patches export the required APIs in the VxLAN and mlxsw drivers in order to allow for the introduction of the NVE core in the next two patches. The NVE core is designed to support a variety of NVE encapsulations (e.g., VxLAN, NVGRE) and different ASICs, but currently only VxLAN and Spectrum are supported. Spectrum-2 support will be added in the future. The last 10 patches add support for VxLAN decapsulation and encapsulation and include the addition of the required switchdev APIs in the VxLAN driver. These APIs allow capable drivers to get a notification about the addition / deletion of FDB entries to / from the VxLAN's FDB. Subsequent patchset will add selftests (generic and mlxsw-specific), data plane learning, FDB extack and vetoing and support for VLAN-aware bridges (one VNI per VxLAN device model). v2: * Implement netif_is_vxlan() using rtnl_link_ops->kind (Jakub & Stephen) ==================== Signed-off-by: -
Ido Schimmel authored
In the device, VxLAN encapsulation takes place in the FDB table where certain {MAC, FID} entries are programmed with an underlay unicast IP. MAC addresses that are not programmed in the FDB are flooded to the relevant local ports and also to a list of underlay unicast IPs that are programmed using the all zeros MAC address in the VxLAN driver. One difference between the hardware and software data paths is the fact that in the software data path there are two FDB lookups prior to the encapsulation of the packet. First in the bridge's FDB table using {MAC, VID} and another in the VxLAN's FDB table using {MAC, VNI}. Therefore, when a new VxLAN FDB entry is notified, it is only programmed to the device if there is a corresponding entry in the bridge's FDB table. Similarly, when a new bridge FDB entry pointing to the VxLAN device is notified, it is only programmed to the device if there is a corresponding entry in the VxLAN's FDB table. Note that the above scheme will result in a discrepancy between both data paths if only one FDB table is populated in the software data path. For example, if only the bridge's FDB is populated with an entry pointing to a VxLAN device, then a packet hitting the entry will only be flooded by the kernel to remote VTEPs whereas the device will also flood the packets to other local ports member in the VLAN. Signed-off-by:Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
-
Ido Schimmel authored
Enslavement of VxLAN devices to offloaded bridges was never forbidden by mlxsw, but this patch makes sure the required configuration is performed in order to allow VxLAN encapsulation and decapsulation to take place in the device. The patch handles both the case where a VxLAN device is enslaved to an already offloaded bridge and the case where the first mlxsw port is enslaved to a bridge that already has VxLAN device configured. Invalid configurations are sanitized and an error string is returned via extack. Since encapsulation and decapsulation do not occur when the VxLAN device is down, the driver makes sure to enable / disable these functionalities based on NETDEV_PRE_UP and NETDEV_DOWN events. Note that NETDEV_PRE_UP is used in favor of NETDEV_UP, as the former allows to veto the operation, if necessary. Signed-off-by:
-
Ido Schimmel authored
Currently, an FDB entry only ceases being offloaded when it is deleted. This changes with VxLAN encapsulation. Devices capable of performing VxLAN encapsulation usually have only one FDB table, unlike the software data path which has two - one in the bridge driver and another in the VxLAN driver. Therefore, bridge FDB entries pointing to a VxLAN device are only offloaded if there is a corresponding entry in the VxLAN FDB. Allow clearing the offload indication in case the corresponding entry was deleted from the VxLAN FDB. Signed-off-by:
-
Petr Machata authored
When notifications are sent about FDB activity, and an FDB entry with several remotes is removed, the notification is sent only for the first destination. That makes it impossible to distinguish between the case where only this first remote is removed, and the one where the FDB entry is removed as a whole. Therefore send one notification for each remote of a removed FDB entry. Signed-off-by:
-
Petr Machata authored
Offloaded bridge FDB entries are marked with NTF_OFFLOADED. Implement a similar mechanism for VXLAN, where a given remote destination can be marked as offloaded. To that end, introduce a new event, SWITCHDEV_VXLAN_FDB_OFFLOADED, through which the marking is communicated to the vxlan driver. To identify which RDST should be marked as offloaded, an switchdev_notifier_vxlan_fdb_info is passed to the listeners. The "offloaded" flag in that object determines whether the offloaded mark should be set or cleared. When sending offloaded FDB entries over netlink, mark them with NTF_OFFLOADED. Signed-off-by:
-
Petr Machata authored
A switchdev-capable driver that is aware of VXLAN may need to query VXLAN FDB. In the particular case of mlxsw, this functionality is limited to querying UC FDBs. Those being easier to deal with than the general case of RDST chain traversal, introduce an interface to query specifically UC FDBs: vxlan_fdb_find_uc(). Signed-off-by:
-
Petr Machata authored
When offloading VXLAN devices, drivers need to know about events in VXLAN FDB database. Since VXLAN models a bridge, it is natural to distribute the VXLAN FDB notifications using the pre-existing switchdev notification mechanism. To that end, introduce two new notification types: SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE and SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE. Introduce a new function, vxlan_fdb_switchdev_call_notifiers() to send the new notifier types, and a struct switchdev_notifier_vxlan_fdb_info to communicate the details of the FDB entry under consideration. Invoke the new function from vxlan_fdb_notify(). Signed-off-by:
-
Ido Schimmel authored
Add the ability to determine whether a netdev is a VxLAN netdev by calling the above mentioned function that checks the netdev's rtnl_link_ops. This will allow modules to identify netdev events involving a VxLAN netdev and act accordingly. For example, drivers capable of VxLAN offload will need to configure the underlying device when a VxLAN netdev is being enslaved to an offloaded bridge. Convert nfp to use the newly introduced helper. Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Ido Schimmel authored
When a local route that matches the source IP of an offloaded NVE tunnel is notified, the driver needs to program it to perform NVE decapsulation instead of merely trapping packets to the CPU. This patch complements "mlxsw: spectrum_router: Enable local routes promotion to perform NVE decap" where existing local routes were promoted to perform NVE decapsulation. Signed-off-by:
-
Ido Schimmel authored
802.1D FIDs are used to represent VLAN-unaware bridges and currently this is the only type of FID that supports NVE configuration. Since the NVE tunnel device does not take a reference on the FID, it is possible for the FID to be destroyed when it still has NVE configuration. Therefore, when destroying the FID make sure to disable its NVE configuration. Signed-off-by:
-
Ido Schimmel authored
The common NVE core expects each encapsulation type to implement a certain set of operations that are specific to this type and the currently used ASIC. These operations include things such as the ability to determine whether a certain NVE configuration can be offloaded and ASIC-specific initialization for this type. Implement these operations for VxLAN on the Spectrum ASIC. Spectrum-2 support will be added by a future patchset. Signed-off-by:
-
Ido Schimmel authored
The Spectrum ASIC supports different types of NVE encapsulations (e.g., VxLAN, NVGRE) with more types to be supported by future ASICs. Despite being different, all these encapsulations share some common functionality such as the enablement of NVE encapsulation on a given filtering identifier (FID) and the addition of remote VTEPs to the linked-list of VTEPs that traffic should be flooded to. Implement this common core and allow different ASICs to register different operations for different encapsulation types. Signed-off-by:
-
Ido Schimmel authored
Drivers that support tunnel decapsulation (IPinIP or NVE) need to configure the underlying device to conform to the behavior outlined in RFC 6040 with respect to the ECN bits. This behavior is implemented by INET_ECN_decapsulate() which requires an skb to be passed where the ECN CE bit can be potentially set. Since these drivers do not need to mark an skb, but only configure the device to do so, factor out the business logic to __INET_ECN_decapsulate() and potentially perform the marking in INET_ECN_decapsulate(). This allows drivers to invoke __INET_ECN_decapsulate() and configure the device. Signed-off-by:
-
Ido Schimmel authored
Drivers that support VxLAN offload need to be able to sanitize the configuration of the VxLAN device and accept / reject its offload. For example, mlxsw requires that the local IP of the VxLAN device be set and that packets be flooded to unicast IP(s) and not to a multicast group. Expose the functions that perform such checks. Signed-off-by:
-
Ido Schimmel authored
In the device, different VRFs (routing tables) are represented using different virtual routers (VRs) and thus the kernel's table IDs are mapped to VR IDs. Allow internal users of the IP router to query the VR ID based on a kernel table ID. This is needed - for example - when configuring the underlay VR where VxLAN encapsulated packets will undergo an L3 lookup. In this case, the kernel's table ID is derived from the VxLAN device's configuration. Signed-off-by:
-
Ido Schimmel authored
When an NVE tunnel with an IP underlay (e.g., VxLAN) is configured the local route to the tunnel's source IP needs to be promoted to perform NVE decapsulation. Expose an API in the unicast IP router to promote / demote local routes. The case where a local route is configured after the creation of the NVE tunnel will be handled in a subsequent patch in the set. Signed-off-by:
-
Ido Schimmel authored
Current APIs only allow looking for a FID and creating it in case it does not exist. With VxLAN, in case the bridge to which the VxLAN device was enslaved does not already have a corresponding FID, then it means that something went wrong that we need to be aware of. Add an API to look up a FID, but without creating it in order to catch above-mentioned situation. Signed-off-by:
-
Ido Schimmel authored
In the device, the VNI and the list of remote VTEPs a packet should be flooded to is a property of the filtering identifier (FID). During encapsulation, the VNI is taken from the FID the packet was classified to. During decapsulation, the overlay packet is injected into a bridge and classified to a FID based on the VNI it came with. Allow NVE configuration for a FID. Currently, this is only supported with 802.1D FIDs which are used for VLAN-unaware bridges. However, NVE configuration is going to be supported with 802.1Q FIDs which is why the related fields are placed in the common FID struct. Since the device requires a 1:1 mapping between FID and VNI, the driver maintains a hashtable keyed by VNI and checks if the VNI is already associated with an existing FID. Signed-off-by:
-
