- 22 Mar, 2021 40 commits
-
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Ido Schimmel authored
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>
-
Nikolay Aleksandrov authored
Recently we had an interop issue where RARP packets got suppressed with bridge neigh suppression enabled, but the check in the code was meant to suppress GARP. Exclude RARP packets from it which would allow some VMWare setups to work, to quote the report: "Those RARP packets usually get generated by vMware to notify physical switches when vMotion occurs. vMware may use random sip/tip or just use sip=tip=0. So the RARP packet sometimes get properly flooded by the vtep and other times get dropped by the logic" Reported-by: Amer Abdalamer <amer@nvidia.com> Signed-off-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Antoine Tenart authored
xps_queue_show is mostly made of an RCU read-side critical section and calls bitmap_zalloc with GFP_KERNEL in the middle of it. That is not allowed as this call may sleep and such behaviours aren't allowed in RCU read-side critical sections. Fix this by using GFP_NOWAIT instead. Fixes: 5478fcd0 ("net: embed nr_ids in the xps maps") Reported-by: kernel test robot <oliver.sang@intel.com> Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Antoine Tenart <atenart@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wei Yongjun authored
Get rid of the CONFIG_PM_SLEEP ifdefery to fix the build error and use __maybe_unused for the suspend()/resume() hooks to avoid build warning: drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:769:21: error: 'stmmac_runtime_suspend' undeclared here (not in a function); did you mean 'stmmac_suspend'? 769 | SET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL) | ^~~~~~~~~~~~~~~~~~~~~~ ./include/linux/pm.h:342:21: note: in definition of macro 'SET_RUNTIME_PM_OPS' 342 | .runtime_suspend = suspend_fn, \ | ^~~~~~~~~~ drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:769:45: error: 'stmmac_runtime_resume' undeclared here (not in a function) 769 | SET_RUNTIME_PM_OPS(stmmac_runtime_suspend, stmmac_runtime_resume, NULL) | ^~~~~~~~~~~~~~~~~~~~~ ./include/linux/pm.h:343:20: note: in definition of macro 'SET_RUNTIME_PM_OPS' 343 | .runtime_resume = resume_fn, \ | ^~~~~~~~~ Fixes: 5ec55823 ("net: stmmac: add clocks management for gmac driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/verifed/verified/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
gcc warns about a pointless condition: drivers/isdn/hardware/mISDN/hfcmulti.c: In function 'hfcmulti_interrupt': drivers/isdn/hardware/mISDN/hfcmulti.c:2752:17: error: suggest braces around empty body in an 'if' statement [-Werror=empty-body] 2752 | ; /* external IRQ */ As the check has no effect, just remove it. Suggested-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
ptype_all and ptype_base are declared in net/core/dev.c as non-static, because they are used by net-procfs.c too. However, a "make W=1" build complains that there was no previous declaration of ptype_all and ptype_base in a header file, so this way of declaring things constitutes a violation of coding style. Let's move the extern declarations of ptype_all and ptype_base to the linux/netdevice.h file, which is included by net-procfs.c too. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Since their introduction in commit 04157469 ("net: Use static_key for XPS maps"), xps_needed and xps_rxqs_needed were never used outside net/core/dev.c, so I don't really understand why they were exported as symbols in the first place. This is needed in order to silence a "make W=1" warning about these static keys not being declared as static variables, but not having a previous declaration in a header file nonetheless. Cc: Amritha Nambiar <amritha.nambiar@intel.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The only caller of br_vlan_tunnel_lookup, br_handle_ingress_vlan_tunnel, extracts the tunnel_id from struct ip_tunnel_info::struct ip_tunnel_key:: tun_id which is a __be64 value. The exact endianness does not seem to matter, because the tunnel id is just used as a lookup key for the VLAN group's tunnel hash table, and the value is not interpreted directly per se. Moreover, rhashtable_lookup_fast treats the key argument as a const void *. Therefore, there is no functional change associated with this patch, just one to silence "make W=1" builds. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiapeng Chong authored
Fix the following coccicheck warnings: ./drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c:3540:2-8: WARNING: NULL check before some freeing functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
Commit 0b529448 ("net: dsa: mv88e6xxx: scratch: Fixup kerneldoc") has addressed some but not all kerneldoc warnings for the Global 2 Scratch register accessors. Namely, we have some mismatches between the function names in the kerneldoc and the ones in the actual code. Let's adjust the comments so that they match the functions they're sitting next to. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Error recovery improvements. This series contains some improvements for error recovery. The main changes are: 1. Keep better track of the health register mappings with the "status_reliable" flag. 2. Don't wait for firmware responses if firmware is not healthy. 3. Better retry logic of the first firmware message. 4. Set the proper flag early to let the RDMA driver know that firmware reset has been detected. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
Two enhancements: 1. Read the health status first before sending the first HWRM_VER_GET message to firmware instead of the other way around. This guarantees we got the accurate health status before we attempt to send the message. 2. We currently only retry sending the first HWRM_VER_GET message to the firmware if the firmware is in the process of booting. If the firmware is in error state and is doing core dump for example, the driver should also retry if the health register has the RECOVERING flag set. This flag indicates the firmware will undergo recovery soon. Modify the retry logic to retry for this case as well. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vasundhara Volam authored
Once the chip goes through reset, the register mapping may be lost and any read of the mapped health registers may return garbage value until the registers are mapped again in the init path. Reading BNXT_FW_RESET_INPROG_REG after firmware reset will likely return garbage value due to the above reason. Reading this register is for information purpose only so remove it. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
During ifup, if the driver detects that firmware has gone through a reset, it will go through a re-probe sequence. If the RDMA driver is loaded, the re-probe sequence includes calling the RDMA driver to stop. We need to set the BNXT_STATE_FW_RESET_DET flag earlier so that it is visible to the RDMA driver. The RDMA driver's stop sequence is different if firmware has gone through a reset. Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: P B S Naresh Kumar <nareshkumar.pbs@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Scott Branden authored
Check return value of call to bnxt_hwrm_func_resc_qcaps in bnxt_hwrm_if_change and return failure on error. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Edwin Peer authored
The original intent here is to allow commands during reset to succeed without error when the device is disabled, to ensure that cleanup completes normally during NIC close, where firmware is not necessarily expected to respond. The problem with faking success during reset's PCI disablement is that unrelated ULP commands will also see inadvertent success during reset when failure would otherwise be appropriate. It is better to return a different error result such that reset related code can detect this unique condition and ignore as appropriate. Note, the pci_disable_device() when firmware is fatally wounded in bnxt_fw_reset_close() does not need to be addressed, as subsequent commands are already expected to fail due to the BNXT_NO_FW_ACCESS() check in bnxt_hwrm_do_send_msg(). Reviewed-by: Scott Branden <scott.branden@broadcom.com> Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Pavan Chebbi authored
In situations where FW has crashed, the bnxt_hwrm_do_send_msg() call will have to wait until timeout for each firmware message. This generally takes about half a second for each firmware message. If we try to unload the driver n this state, the unload sequence will take a long time to complete. Improve this by checking the health register if it is available and abort the wait for the firmware response if the register shows that firmware is not healthy. The very first message HWRM_VER_GET is excluded from this check because that message is used to poll for firmware to come out of reset during error recovery. Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Michael Chan authored
In order to read the firmware health status, we first need to determine the register location and then the register may need to be mapped. There are 2 code paths to do this. The first one is done early as a best effort attempt by the function bnxt_try_map_fw_health_reg(). The second one is done later in the function bnxt_map_fw_health_regs() after establishing communications with the firmware. We currently only set fw_health->status_reliable if we can successfully set up the health register in the first code path. Improve the scheme by setting the fw_health->status_reliable flag if either (or both) code paths can successfully set up the health register. This flag is relied upon during run-time when we need to check the health status. So this will make it work better. During ifdown, if the health register is mapped, we need to invalidate the health register mapping because a potential fw reset will reset the mapping. Similarly, we need to do the same after firmware reset during recovery. We'll remap it during ifup. Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: refactor and new features for flow director This patchset refactor some functions and add some new features for flow director. patch 1~3: refactor large functions patch 4, 7: add traffic class and user-def field support for ethtool patch 5: refactor flow director configuration patch 6: clean up for hns3_del_all_fd_entries() change log: V1->V2: modifies patch 5 as Jakub suggested, keep configuring ethtool/tc flower rules synchronously while aRFS asynchronously. changes the usecnt of user-def rule checking in patch 7. removes previous patches 8 and 9 from this series, since there are issues that need further discussion. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
For DEVICE_VERSION_V3, the hardware supports to match specified data in the specified offset of packet payload. Each layer can have one offset, and can't be masked when configure flow director rule by ethtool command. The layer is selected based on the flow-type, ether for L2, ip4/ipv6 for L3, and tcp4/tcp6/udp4/udp6 for L4. For example, tcp4/tcp6/udp4/udp6 rules share the same user-def offset, but each rule can have its own user-def value. For the user-def field of ethtool -N/U command is 64 bits long. The bit 0~15 is used for user-def value, and bit 32~47 for user-def offset in HNS3 driver. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
For only PF driver can configure flow director rule, it's better to call hclge_del_all_fd_entries() directly in hclge layer, rather than call hns3_del_all_fd_entries() in hns3 layer. Then the ae_algo->ops.del_all_fd_entries can be removed. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
Currently, the flow director rule of aRFS is configured in the IO path. It's time-consuming. So move out the configuration, and configure it asynchronously. And keep ethtool and tc flower rule using synchronous way, otherwise the application maybe unable to know the rule is installed or pending. Add a state member for each flow director rule to indicate the rule state. There are 4 states: TO_ADD: the rule is waiting to add to hardware TO_DEL: the rule is waiting to remove from hardware DELETED: the rule has been removed from hardware. It's a middle state, used to remove the rule node in the fd_rule_list. ACTIVE: the rule is already added in hardware For asynchronous way, when receive a new request to add or delete flow director rule by aRFS, update the rule list, then request to schedule the service task to finish the configuration. For synchronous way, when receive a new request to add or delete flow director rule by ethtool or tc flower, configure hardware directly, then update the rule list if success. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
The hardware supports to parse and match the traffic class field of IPv6 packet for flow director, uses the same tuple as ip tos. So removes the limitation of configure 'tclass' by driver. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
Currently, there are too many branches for hclge_fd_convert_tuple(). And it may be more when add new tuples. Refactor it by sorting the tuples according to their length. So it only needs several KEY_OPT now, and being flexible to add new tuples. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
The process of function hclge_fd_get_tuple() is complex and prolix. To make it more readable, extract the process of each flow-type tuple to a single function. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jian Shen authored
The process of function hclge_add_fd_entry() is complex and prolix. To make it more readable, extract the process of fs->ring_cookie to a single function. Signed-off-by: Jian Shen <shenjian15@huawei.com> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/unrequired/"not required"/ s/consme/consume/ .....two different places s/accros/across/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/subsytem/subsystem/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Bhaskar Chowdhury authored
s/packaet/packet/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Cristian Ciocaltea says: ==================== Add support for Actions Semi Owl Ethernet MAC This patch series adds support for the Ethernet MAC found on the Actions Semi Owl family of SoCs. For the moment I have only tested the driver on RoseapplePi SBC, which is based on the S500 SoC variant. It might work on S900 as well, but I cannot tell for sure since the S900 datasheet I currently have doesn't provide any information regarding the MAC registers - so I couldn't check the compatibility with S500. Similar story for S700: the datasheet I own is incomplete, but it seems the MAC is advertised with Gigabit capabilities. For that reason most probably we need to extend the current implementation in order to support this SoC variant as well. Please note that for testing the driver it is also necessary to update the S500 clock subsystem: https://lore.kernel.org/lkml/cover.1615221459.git.cristian.ciocaltea@gmail.com/ The DTS changes for the S500 SBCs will be provided separately. Thanks, Cristi Changes in v3: - Dropped the 'debug' module parameter and passed the default NETIF_MSG flags to netif_msg_init(), according to David's review - Removed the owl_emac_generate_mac_addr() function and the related OWL_EMAC_GEN_ADDR_SYS_SN config option until a portable solution to get the system serial number is found - when building on arm64 the following error is thrown (as reported by Rob's kernel bot): '[...]/owl-emac.c:9:10: fatal error: asm/system_info.h: No such file or directory' - Rebased patchset on v5.12-rc4 Changes in v2: * According to Philipp's review - Requested exclusive control over serial line via devm_reset_control_get_exclusive() - Optimized error handling by using dev_err_probe() * According to Andrew's review - Dropped the inline keywords - Applied Reverse Christmas Tree format to local variable declarations - Renamed owl_emac_phy_config() to owl_emac_update_link_state() - Documented the purpose of the special descriptor used in the context of owl_emac_setup_frame_xmit() - Updated comment inside owl_emac_mdio_clock_enable() regarding the MDC clock divider setup - Indicated MAC support for symmetric pause via phy_set_sym_pause() in owl_emac_phy_init() - Changed the MAC addr generation algorithm in owl_emac_generate_mac_addr() by setting the locally administered bit in byte 0 and replacing bytes 1 & 2 with additional entries from enc_sn - Moved devm_add_action_or_reset() before clk_set_rate() in owl_emac_probe() * Other - Added SMII interface support: updated owl_emac_core_sw_reset(), added owl_emac_clk_set_rate(), updated description in the YAML binding - Changed OWL_EMAC_TX_TIMEOUT from 0.05*HZ to 2*HZ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cristian Ciocaltea authored
Add entries for Actions Semi Owl Ethernet MAC binding and driver. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Cristian Ciocaltea authored
Add new driver for the Ethernet MAC used on the Actions Semi Owl family of SoCs. Currently this has been tested only on the Actions Semi S500 SoC variant. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-