summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2021-03-24net: ethernet: mtk_eth_soc: add support for initializing the PPEFelix Fietkau7-3/+1190
The PPE (packet processing engine) is used to offload NAT/routed or even bridged flows. This patch brings up the PPE and uses it to get a packet hash. It also contains some functionality that will be used to bring up flow offloading. Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ethernet: mtk_eth_soc: fix parsing packets in GDMFelix Fietkau2-6/+11
When using DSA, set the special tag in GDM ingress control to allow the MAC to parse packets properly earlier. This affects rx DMA source port reporting. Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24ch_ktls: fix enum-conversion warningArnd Bergmann1-1/+1
gcc points out an incorrect enum assignment: drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c: In function 'chcr_ktls_cpl_set_tcb_rpl': drivers/net/ethernet/chelsio/inline_crypto/ch_ktls/chcr_ktls.c:684:22: warning: implicit conversion from 'enum <anonymous>' to 'enum ch_ktls_open_state' [-Wenum-conversion] This appears harmless, and should apparently use 'CH_KTLS_OPEN_SUCCESS' instead of 'false', with the same value '0'. Fixes: efca3878a5fb ("ch_ktls: Issue if connection offload fails") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24octeontx2-af: Fix memory leak of object bufColin Ian King1-1/+3
Currently the error return path when lfs fails to allocate is not free'ing the memory allocated to buf. Fix this by adding the missing kfree. Addresses-Coverity: ("Resource leak") Fixes: f7884097141b ("octeontx2-af: Formatting debugfs entry rsrc_alloc.") Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ocelot: Simplify MRP deletionHoratiu Vultur1-16/+0
Now that the driver will always be notified that the role is deleted before the ring is deleted, then we don't need to duplicate the logic of cleaning the resources also in the delete function. Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove redundant variable initializationYonglong Liu7-17/+17
There are some variables in HNS driver will not being referenced before assigned, so there is no need to init them. Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unnecessary !! operation in hns_mac_config_sds_loopback_acpi()Yonglong Liu1-1/+1
The !! operation of variable en in hns_mac_config_sds_loopback_acpi() is redundant, so remove it. Signed-off-by: Yonglong Liu <liuyonglong@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused HNS_LED_PC_REGHuazhong Tan1-1/+0
HNS_LED_PC_REG is not used and can be removed. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused NIC_LB_TEST_RX_PKG_ERRHuazhong Tan1-1/+1
NIC_LB_TEST_RX_PKG_ERR is not used and can be removed. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused config_half_duplex()Huazhong Tan3-12/+0
Since config_half_duplex() in struct mac_driver is unused, so remove it. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused set_rx_ignore_pause_frames()Huazhong Tan3-26/+0
Since set_rx_ignore_pause_frames() in struct mac_driver is unused, so remove it. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused set_autoneg()Huazhong Tan2-11/+0
Since set_autoneg() in struct hnae_ae_ops is unused, so remove it. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: hns: remove unused get_autoneg()Huazhong Tan2-15/+0
Since get_autoneg() in struct hnae_ae_ops is unused, so remove it. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ethernet: Remove duplicate include of vhca_event.hWan Jiabing1-1/+0
vhca_event.h has been included at line 4, so remove the duplicate one at line 8. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ethernet: indir_table.h is included twiceWan Jiabing1-1/+0
indir_table.h has been included at line 41, so remove the duplicate one at line 43. Signed-off-by: Wan Jiabing <wanjiabing@vivo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24Merge branch '100GbE' of ↵David S. Miller48-69/+90
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2021-03-23 This series contains updates to ice, fm10k, i40e, iavf, ixgbe, ixgbevf, igb, e1000e, and e1000 drivers. Tony fixes prototype warnings for mismatched header for ice driver. Sasha fixes prototype warnings for mismatched header for igc and e1000e driver. Jesse fixes prototype warnings for mismatched header for the remaining Intel drivers: fm10k, i40e, iavf, igb, ixgbe, and ixgbevf. Gustavo A. R. Silva explicitly adds a break instead of falling through in preparation of -Wimplicit-fallthrough for Clang to ice, fm10k, ixgbe, igb, ixgbevf, and e1000 drivers, ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ocelot: replay switchdev events when joining bridgeVladimir Oltean3-31/+107
The premise of this change is that the switchdev port attributes and objects offloaded by ocelot might have been missed when we are joining an already existing bridge port, such as a bonding interface. The patch pulls these switchdev attributes and objects from the bridge, on behalf of the 'bridge port' net device which might be either the ocelot switch interface, or the bonding upper interface. The ocelot_net.c belongs strictly to the switchdev ocelot driver, while ocelot.c is part of a library shared with the DSA felix driver. The ocelot_port_bridge_leave function (part of the common library) used to call ocelot_port_vlan_filtering(false), something which is not necessary for DSA, since the framework deals with that already there. So we move this function to ocelot_switchdev_unsync, which is specific to the switchdev driver. The code movement described above makes ocelot_port_bridge_leave no longer return an error code, so we change its type from int to void. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-24net: ocelot: call ocelot_netdevice_bridge_join when joining a bridged LAGVladimir Oltean1-25/+86
Similar to the DSA situation, ocelot supports LAG offload but treats this scenario improperly: ip link add br0 type bridge ip link add bond0 type bond ip link set bond0 master br0 ip link set swp0 master bond0 We do the same thing as we do there, which is to simulate a 'bridge join' on 'lag join', if we detect that the bonding upper has a bridge upper. Again, same as DSA, ocelot supports software fallback for LAG, and in that case, we should avoid calling ocelot_netdevice_changeupper. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23e1000: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23ixgbevf: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23igb: Fix fall-through warnings for ClangGustavo A. R. Silva3-0/+3
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23ixgbe: Fix fall-through warnings for ClangGustavo A. R. Silva4-0/+5
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23fm10k: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+2
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding a couple of break statements instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23ice: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of just letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23intel: clean up mismatched header commentsJesse Brandeburg29-53/+61
A bunch of header comments were showing warnings when compiling with W=1. Fix them all at once. This changes only comments. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23e1000e: Fix prototype warningSasha Neftin4-7/+7
Correct report warnings in ich8lan.c, netdev.c phy.c and ptp.c files Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23igc: Fix prototype warningSasha Neftin1-1/+1
Correct report warnings in igc_i225.c Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Acked-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-23ice: Fix prototype warningsTony Nguyen6-8/+8
Correct reported warnings for "warning: expecting prototype for ... Prototype was for ... instead" Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
2021-03-23net: stmmac: merge ARCH_SOCFPGA and ARCH_STRATIX10Krzysztof Kozlowski1-2/+2
Simplify 32-bit and 64-bit Intel SoCFPGA Kconfig options by having only one for both of them. This the common practice for other platforms. Additionally, the ARCH_SOCFPGA is too generic as SoCFPGA designs come from multiple vendors. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2021-03-23dpaa2-switch: mark skbs with offload_fwd_markIoana Ciornei1-0/+3
If a switch port is under a bridge, the offload_fwd_mark should be setup before sending the skb towards the stack so that the bridge does not try to flood the packet on the other switch ports. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23dpaa2-switch: add support for configuring per port unknown floodingIoana Ciornei2-3/+21
Add support for configuring per port unknown flooding by accepting both BR_FLOOD and BR_MCAST_FLOOD as offloadable bridge port flags. The DPAA2 switch does not support at the moment configuration of unknown multicast flooding independently of unknown unicast flooding, therefore check that both BR_FLOOD and BR_MCAST_FLOOD have the same state. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23dpaa2-switch: add support for configuring per port broadcast floodingIoana Ciornei2-3/+31
The BR_BCAST_FLOOD bridge port flag is now accepted by the driver and a change in its state will determine a reconfiguration of the broadcast egress flooding list on the FDB associated with the port. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23dpaa2-switch: add support for configuring learning state per portIoana Ciornei4-11/+121
Add support for configuring the learning state of a switch port. When the user requests the HW learning to be disabled, a fast-age procedure on that specific port is run so that previously learnt addresses do not linger. At device probe as well as on a bridge leave action, the ports are configured with HW learning disabled since they are basically a standalone port. At the same time, at bridge join we inherit the bridge port BR_LEARNING flag state and configure it on the switch port. There were already some MC firmware ABI functions for changing the learning state, but those were per FDB (bridging domain) and not per port so we need to adjust those to use the new MC fw command which is per port. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23dpaa2-switch: refactor the egress flooding domain setupIoana Ciornei1-13/+25
Extract the code that determines the list of egress flood interfaces for a specific flood type into a new function - dpaa2_switch_fdb_get_flood_cfg(). This will help us to not duplicate code when the broadcast and unknown ucast/mcast flooding domains will be individually configurable. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23dpaa2-switch: move the dpaa2_switch_fdb_set_egress_flood functionIoana Ciornei1-42/+42
In order to avoid a forward declaration in the next patches, move the dpaa2_switch_fdb_set_egress_flood() function to the top of the file. Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-23Merge branch '100GbE' of ↵David S. Miller28-84/+6210
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 100GbE Intel Wired LAN Driver Updates 2021-03-22 This series contains updates to ice and iavf drivers. Haiyue Wang says: The Intel E810 Series supports a programmable pipeline for a domain specific protocols classification, for example GTP by Dynamic Device Personalization (DDP) profile. The E810 PF has introduced flex-bytes support by ethtool user-def option allowing for packet deeper matching based on an offset and value for DDP usage. For making VF also benefit from this flexible protocol classification, some new virtchnl messages are defined and handled by PF, so VF can query this new flow director capability, and use ethtool with extending the user-def option to configure Rx flow classification. The new user-def 0xAAAABBBBCCCCDDDD: BBBB is the 2 byte pattern while AAAA corresponds to its offset in the packet. Similarly DDDD is the 2 byte pattern with CCCC being the corresponding offset. The offset ranges from 0x0 to 0x1F7 (up to 504 bytes into the packet). The offset starts from the beginning of the packet. This feature can be used to allow customers to set flow director rules for protocols headers that are beyond standard ones supported by ethtool (e.g. PFCP or GTP-U). Like for matching GTP-U's TEID value 0x10203040: ethtool -N ens787f0v0 flow-type udp4 dst-port 2152 \ user-def 0x002e102000303040 action 13 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Add Spectrum-{2, 3} adjacency group size rangesIdo Schimmel2-10/+32
Spectrum-{2,3} support different adjacency group size ranges compared to Spectrum-1. Add an array describing these ranges and change the common code to use the array which was set during the per-ASIC initialization. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Encode adjacency group size ranges in an arrayIdo Schimmel1-21/+44
The device supports a fixed set of adjacency group sizes. Encode these sizes in an array, so that the next patch will be able to split it between Spectrum-1 and Spectrum-{2,3}, which support different size ranges. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Create per-ASIC router operationsIdo Schimmel3-10/+41
There are several differences in the router module between Spectrum-1 and Spectrum-{2,3}. Currently, this is only apparent in the router interface (RIF) operations that are split between these ASICs. A subsequent patch is going to introduce another difference between these ASICs. Create per-ASIC router operations that will encapsulate all these differences. For now, these operations are only used to set the per-ASIC RIF operations in 'mlxsw_sp->router->rif_ops_arr'. Note that this fields was unused since commit 1f5b23033937 ("mlxsw: spectrum: Set RIF ops per ASIC type"). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Avoid unnecessary neighbour updatesIdo Schimmel1-0/+4
Avoid updating neighbour and adjacency entries in hardware when the neighbour is already connected and its MAC address did not change. This can happen, for example, when neighbour transitions between valid states such as 'NUD_REACHABLE' and 'NUD_DELAY'. This is especially important for resilient hashing as these updates will result in adjacency entries being marked as active. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Break nexthop group entry validation to a separate ↵Ido Schimmel1-11/+25
function The validation of a nexthop group entry is also necessary for resilient nexthop groups, so break the validation to a separate function to allow for code reuse in subsequent patches. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Encapsulate nexthop update in a functionIdo Schimmel1-13/+15
Encapsulate this functionality in a separate function, so that it could be invoked by follow-up patches, when replacing a nexthop bucket that is part of a resilient nexthop group. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Rename nexthop update function to reflect its typeIdo Schimmel3-11/+14
mlxsw_sp_nexthop_update() is used to update the configuration of Ethernet-type nexthops, as opposed to mlxsw_sp_nexthop_ipip_update(), which is used to update IPinIP-type nexthops. Rename the function to mlxsw_sp_nexthop_eth_update(), so that it is consistent with mlxsw_sp_nexthop_ipip_update(). It will allow us to introduce mlxsw_sp_nexthop_update() in a follow-up patch, which calls either of above mentioned function based on the nexthop's type. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Add nexthop trap action supportIdo Schimmel1-13/+29
Currently, nexthops are programmed with either forward or discard action (for blackhole nexthops). Nexthops that do not have a valid MAC address (neighbour) or router interface (RIF) are simply not written to the adjacency table. In resilient nexthop groups, the size of the group must remain fixed and the kernel is in complete control of the layout of the adjacency table. A nexthop without a valid MAC or RIF will therefore be written with a trap action, to trigger neighbour resolution. Allow such nexthops to be programmed to the adjacency table to enable above mentioned use case. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Prepare for nexthops with trap actionIdo Schimmel1-1/+4
Nexthops that need to be programmed with a trap action might not have a valid router interface (RIF) associated with them. Therefore, use the loopback RIF created during initialization to program them to the device. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Introduce nexthop action fieldIdo Schimmel1-8/+17
Currently, the action associated with the nexthop is assumed to be 'forward' unless the 'discard' bit is set. Instead, simplify this by introducing a dedicated field to represent the action of the nexthop. This will allow us to more easily introduce more actions, such as trap. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Adjust comments on nexthop fieldsIdo Schimmel1-6/+6
The comments assume that nexthops are simple Ethernet nexthops that are programmed to forward packets to the associated neighbour. This is no longer the case, as both IPinIP and blackhole nexthops are now supported. Adjust the comments to reflect these changes. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Only provide MAC address for valid nexthopsIdo Schimmel1-1/+2
The helper returns the MAC address associated with the nexthop. It is only valid when the nexthop forwards packets and when it is an Ethernet nexthop. Reflect this in the checks the helper is performing. This is not an issue because the sole caller of the function only invokes it for such nexthops. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Consolidate nexthop helpersIdo Schimmel3-18/+9
The helper mlxsw_sp_nexthop_offload() is actually interested in finding out if the nexthop is both written to the adjacency table and forwarding packets (as opposed to discarding them). Rename it to mlxsw_sp_nexthop_is_forward() and remove mlxsw_sp_nexthop_is_discard(). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-22mlxsw: spectrum_router: Remove RTNL assertionIdo Schimmel1-2/+0
Remove the RTNL assertion in the nexthop notifier block. The assertion is not needed given RTNL is never assumed to be taken. This is a preparation for future patches where mlxsw will start handling nexthop events that are not always sent with RTNL held. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>