summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2020-11-18mlxsw: spectrum_router: Add an indication if a nexthop group can be destroyedIdo Schimmel1-0/+9
Currently, a nexthop group is destroyed when the last FIB entry is detached from it. When nexthop objects are supported, this can no longer be the case, as the group is a separate object whose lifetime is managed by user space. Add an indication if a nexthop group can be destroyed and always set it to true for the existing IPv4 and IPv6 nexthop groups. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Only clear offload indication from valid IPv6 FIB infoIdo Schimmel1-1/+2
When the IPv6 FIB info has a nexthop object, the nexthop offload indication is set on the nexthop object and not on the FIB info itself. Therefore, do not try to clear the offload indication from the FIB info when it has a nexthop object. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Re-order mlxsw_sp_nexthop6_group_get()Ido Schimmel1-4/+4
Attach the FIB entry to the nexthop group after setting the offload flag on the IPv6 FIB info (i.e., 'struct fib6_info'). The second operation is not needed when the nexthop group is a nexthop object. This will allow us to have a common exit path from the function, regardless of the nexthop group's type. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Set FIB entry's type based on nexthop groupIdo Schimmel1-5/+5
The previous patch associated a nexthop group with the FIB entry before the entry's type is determined. Make use of the nexthop group when determining the entry's type instead of relying on helpers that assume that the nexthop info is not a nexthop object (i.e., 'struct nexthop'). Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Set FIB entry's type after creating nexthop groupIdo Schimmel1-9/+9
Each FIB entry has a type (e.g., remote, local) that determines how the entry is programmed to the device. In order to determine if the entry is local (directly connected) or remote (has a gateway) the relevant FIB info structures (e.g., 'struct fib_info') are checked. When entries that use nexthop objects are supported, these checks will need to be changed to take into account 'struct nexthop'. Instead, first associate the entry with a nexthop group so that the next patch could determine the entry's type based on the associated nexthop group's type. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Pass ifindex to mlxsw_sp_ipip_entry_find_by_decap()Ido Schimmel1-6/+18
The sole caller of the function will soon only have the ifindex available, instead of the pointer itself. Therefore, change the function to take the ifindex as input and have it get the pointer. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Set ifindex for IPv4 nexthopsIdo Schimmel1-0/+1
The ifindex of the nexthop device was never set for IPv4 nexthops, unlike IPv6 nexthops. This went unnoticed since only IPv6 nexthops use it. Set the ifindex for IPv4 nexthops in order to be consistent with IPv6 and also because it will be used by a later patch. Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: spectrum_router: Fix wrong kfree() in error pathIdo Schimmel1-1/+1
The function allocates 'nhgi', not 'nh_grp', so it needs to free the former in its error path. Fixes: 7f7a417e6a11 ("mlxsw: spectrum_router: Split nexthop group configuration to a different struct") Addresses-Coverity: ("Memory - corruptions (USE_AFTER_FREE)") Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: core: Use variable timeout for EMAD retriesIdo Schimmel1-1/+2
The driver sends Ethernet Management Datagram (EMAD) packets to the device for configuration purposes and waits for up to 200ms for a reply. A request is retried up to 5 times. When the system is under heavy load, replies are not always processed in time and EMAD transactions fail. Make the process more robust to such delays by using exponential backoff. First wait for up to 200ms, then retransmit and wait for up to 400ms and so on. Fixes: caf7297e7ab5 ("mlxsw: core: Introduce support for asynchronous EMAD register access") Reported-by: Denis Yulevich <denisyu@nvidia.com> Tested-by: Denis Yulevich <denisyu@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18mlxsw: Fix firmware flashingIdo Schimmel1-1/+1
The commit cited below moved firmware flashing functionality from mlxsw_spectrum to mlxsw_core, but did not adjust the Kconfig dependencies. This makes it possible to have mlxsw_core as built-in and mlxfw as a module. The mlxfw code is therefore not reachable from mlxsw_core and firmware flashing fails: # devlink dev flash pci/0000:01:00.0 file mellanox/mlxsw_spectrum-13.2008.1310.mfa2 devlink answers: Operation not supported Fix by having mlxsw_core select mlxfw. Fixes: b79cb787ac70 ("mlxsw: Move fw flashing code into core.c") Signed-off-by: Ido Schimmel <idosch@nvidia.com> Reported-by: Vadim Pasternak <vadimp@nvidia.com> Tested-by: Vadim Pasternak <vadimp@nvidia.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18atl1e: fix error return code in atl1e_probe()Zhang Changzhong1-2/+2
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: a6a5325239c2 ("atl1e: Atheros L1E Gigabit Ethernet driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1605581875-36281-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18atl1c: fix error return code in atl1c_probe()Zhang Changzhong1-2/+2
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 43250ddd75a3 ("atl1c: Atheros L1C Gigabit Ethernet driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1605581721-36028-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18nfp: tls: Fix unreachable code issueGustavo A. R. Silva1-1/+1
Fix the following unreachable code issue: drivers/net/ethernet/netronome/nfp/crypto/tls.c: In function 'nfp_net_tls_add': include/linux/compiler_attributes.h:208:41: warning: statement will never be executed [-Wswitch-unreachable] 208 | # define fallthrough __attribute__((__fallthrough__)) | ^~~~~~~~~~~~~ drivers/net/ethernet/netronome/nfp/crypto/tls.c:299:3: note: in expansion of macro 'fallthrough' 299 | fallthrough; | ^~~~~~~~~~~ Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Simon Horman <simon.horman@netronome.com> Link: https://lore.kernel.org/r/20201117171347.GA27231@embeddedor Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18qed: fix ILT configuration of SRC blockDmitry Bogdanov2-5/+2
The code refactoring of ILT configuration was not complete, the old unused variables were used for the SRC block. That could lead to the memory corruption by HW when rx filters are configured. This patch completes that refactoring. Fixes: 8a52bbab39c9 (qed: Debug feature: ilt and mdump) Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Ariel Elior <aelior@marvell.com> Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com> Link: https://lore.kernel.org/r/20201116132944.2055-1-dbogdanov@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Delete NIX_RXVLAN_ALLOC mailbox messageSubbaraya Sundeep4-90/+0
Since mailbox message for installing flows is in place, remove the RXVLAN_ALLOC mbox message which is redundant. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Add new mbox messages to retrieve MCAM entriesNaveen Mamindlapalli2-0/+92
This patch introduces new mailbox mesages to retrieve a given MCAM entry or base flow steering rule of a VF installed by its parent PF. This helps while updating the existing MCAM rules with out re-framing the whole mailbox request again. The INSTALL FLOW mailbox consumer can read-modify-write the existing entry. Similarly while installing new flow rules for a VF, the base flow steering rule match creteria is copied to the new flow rule and the deltas are appended to the new rule. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Co-developed-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Handle PF-VF mac address changesHariprasad Kelam4-4/+36
This patch handles the VF mac address changes as given below. 1. mac addr configrued by VF will be retained until VF module unload. 2. mac addr configred by PF for VF will be retained until power cycle. 3. mac addr confgired by PF for its VF can't be overwritten by VF. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-pf: Add support for SR-IOV management functionsNaveen Mamindlapalli9-2/+420
This patch adds support for ndo_set_vf_mac, ndo_set_vf_vlan and ndo_get_vf_config handlers. The traffic redirection based on the VF mac address or vlan id is done by installing MCAM rules. Reserved RX_VTAG_TYPE7 in each NIXLF for VF VLAN which strips the VLAN tag from ingress VLAN traffic. The NIX PF allocates two MCAM entries for VF VLAN feature, one used for ingress VTAG strip and another entry for egress VTAG insertion. This patch also updates the MAC address in PF installed VF VLAN rule upon receiving nix_lf_start_rx mbox request for VF since Administrative Function driver will assign a valid MAC addr in nix_lf_start_rx function. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Co-developed-by: Tomasz Duszynski <tduszynski@marvell.com> Signed-off-by: Tomasz Duszynski <tduszynski@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-pf: Implement ingress/egress VLAN offloadHariprasad Kelam8-4/+167
This patch implements egress VLAN offload by appending NIX_SEND_EXT_S header to NIX_SEND_HDR_S. The VLAN TCI information is specified in the NIX_SEND_EXT_S. The VLAN offload in the ingress path is implemented by configuring the NIX_RX_VTAG_ACTION_S to strip and capture the outer vlan fields. The NIX PF allocates one MCAM entry for Rx VLAN offload. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Modify nix_vtag_cfg mailbox to support TX VTAG entriesVamsi Attunuru3-13/+250
This patch modifies the existing nix_vtag_config mailbox message to allocate and free TX VTAG entries as requested by a NIX PF. The TX VTAG entries are global resource that shared by all PFs and each entry specifies the size of VTAG to insert and the VTAG header data to insert. The mailbox response contains the entry index which is used by mailbox requester in configuring the NPC_TX_VTAG_ACTION for any MCAM entry. Signed-off-by: Vamsi Attunuru <vattunuru@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Add debugfs entry to dump the MCAM rulesSubbaraya Sundeep1-0/+197
Add debugfs support to dump the MCAM rules installed using NPC_INSTALL_FLOW mbox message. Debugfs file can display mcam entry, counter if any, flow type and counter hits. Ethtool will dump the ntuple flows related to the PF only. The debugfs file gives systemwide view of the MCAM rules installed by all the PF's. Below is the example output when the debugfs file is read: ~ # mount -t debugfs none /sys/kernel/debug ~ # cat /sys/kernel/debug/octeontx2/npc/mcam_rules Installed by: PF1 direction: RX mcam entry: 227 udp source port 23 mask 0xffff Forward to: PF1 VF0 action: Direct to queue 0 enabled: yes counter: 1 hits: 0 Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-pf: Add support for unicast MAC address filteringHariprasad Kelam3-7/+143
Add unicast MAC address filtering support using install flow message. Total of 8 MCAM entries are allocated for adding unicast mac filtering rules. If the MCAM allocation fails, the unicast filtering support will not be advertised. Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-pf: Add support for ethtool ntuple filtersSubbaraya Sundeep5-5/+707
This patch adds support for adding and deleting ethtool ntuple filters. The filters for ether, ipv4, ipv6, tcp, udp and sctp are supported. The mask is also supported. The supported actions are drop and direct to a queue. Additionally we support FLOW_EXT field vlan_tci and FLOW_MAC_EXT. The NIX PF will allocate total 32 MCAM entries for the use of ethtool ntuple filters. The Administrative Function(AF) will install/delete the MCAM rules when NIX PF sends mailbox message to install/delete the ntuple filters. Ethtool ntuple filters support is restricted to PFs as of now and PF can install ntuple filters to direct the traffic to its VFs. Hence added a separate callback for VFs to get/set RSS configuration. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Add mbox messages to install and delete MCAM rulesSubbaraya Sundeep8-52/+1064
Added new mailbox messages to install and delete MCAM rules. These mailbox messages will be used for adding/deleting ethtool n-tuple filters by NIX PF. The installed MCAM rules are stored in a list that will be traversed later to delete the MCAM entries when the interface is brought down or when PCIe FLR is received. The delete mailbox supports deleting a single MCAM entry or range of entries or all the MCAM entries owned by the pcifunc. Each MCAM entry can be associated with a HW match stat entry if the mailbox requester wants to check the hit count for debugging. Modified adding default unicast DMAC match rule using install flow API. The default unicast DMAC match entry installed by Administrative Function is saved and can be changed later by the mailbox user to fit additional fields, or the default MCAM entry rule action can be used for other flow rules installed later. Modified rvu_mbox_handler_nix_lf_free mailbox to add a flag to disable or delete the MCAM entries. The MCAM entries are disabled when the interface is brought down and deleted in FLR handler. The disabled MCAM entries will be re-enabled when the interface is brought up again. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Generate key field bit mask from KEX profileSubbaraya Sundeep5-3/+658
Key Extraction(KEX) profile decides how the packet metadata such as layer information and selected packet data bytes at each layer are placed in MCAM search key. This patch reads the configured KEX profile parameters to find out the bit position and bit mask for each field. The information is used when programming the MCAM match data by SW to match a packet flow and take appropriate action on the flow. This patch also verifies the mandatory fields such as channel and DMAC are not overwritten by the KEX configuration of other fields. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Verify MCAM entry channel and PF_FUNCSubbaraya Sundeep3-2/+82
This patch adds support to verify the channel number sent by mailbox requester before writing MCAM entry for Ingress packets. Similarly for Egress packets, verifying the PF_FUNC sent by the mailbox user. Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Kiran Kumar K <kirankumark@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18octeontx2-af: Modify default KEX profile to extract TX packet fieldsStanislaw Kardach3-14/+120
The current default Key Extraction(KEX) profile can only use RX packet fields while generating the MCAM search key. The profile can't be used for matching TX packet fields. This patch modifies the default KEX profile to add support for extracting TX packet fields into MCAM search key. Enabled Tx KPU packet parsing by configuring TX PKIND in tx_parse_cfg. Modified the KEX profile to extract 2 bytes of VLAN TCI from an offset of 2 bytes from LB_PTR. The LB_PTR points to the byte offset where the VLAN header starts. The NPC KPU parser profile has been modified to point LB_PTR to the starting byte offset of VLAN header which points to the tpid field. Signed-off-by: Stanislaw Kardach <skardach@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-18i40e: Use batched xsk Tx interfaces to increase performanceMagnus Karlsson4-35/+112
Use the new batched xsk interfaces for the Tx path in the i40e driver to improve performance. On my machine, this yields a throughput increase of 4% for the l2fwd sample app in xdpsock. If we instead just look at the Tx part, this patch set increases throughput with above 20% for Tx. Note that I had to explicitly loop unroll the inner loop to get to this performance level, by using a pragma. It is honored by both clang and gcc and should be ignored by versions that do not support it. Using the -funroll-loops compiler command line switch on the source file resulted in a loop unrolling on a higher level that lead to a performance decrease instead of an increase. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/1605525167-14450-6-git-send-email-magnus.karlsson@gmail.com
2020-11-18i40e: Remove unnecessary sw_ring access from xsk TxMagnus Karlsson1-5/+1
Remove the unnecessary access to the software ring for the AF_XDP zero-copy driver. This was used to record the length of the packet so that the driver Tx completion code could sum this up to produce the total bytes sent. This is now performed during the transmission of the packet, so no need to record this in the software ring. Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/1605525167-14450-3-git-send-email-magnus.karlsson@gmail.com
2020-11-17enetc: Workaround for MDIO register access issueAlex Marginean4-25/+161
Due to a hardware issue, an access to MDIO registers that is concurrent with other ENETC register accesses may lead to the MDIO access being dropped or corrupted. The workaround introduces locking for all register accesses to the ENETC register space. To reduce performance impact, a readers-writers locking scheme has been implemented. The writer in this case is the MDIO access code (irrelevant whether that MDIO access is a register read or write), and the reader is any access code to non-MDIO ENETC registers. Also, the datapath functions acquire the read lock fewer times and use _hot accessors. All the rest of the code uses the _wa accessors which lock every register access. The commit introducing MDIO support is - commit ebfcb23d62ab ("enetc: Add ENETC PF level external MDIO support") but due to subsequent refactoring this patch is applicable on top of a later commit. Fixes: 6517798dd343 ("enetc: Make MDIO accessors more generic and export to include/linux/fsl") Signed-off-by: Alex Marginean <alexandru.marginean@nxp.com> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> Link: https://lore.kernel.org/r/20201112182608.26177-1-claudiu.manoil@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net/mlx5: fix error return code in mlx5e_tc_nic_init()Wang Hai1-1/+3
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: aedd133d17bc ("net/mlx5e: Support CT offload for tc nic flows") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5: E-Switch, Fail mlx5_esw_modify_vport_rate if qos disabledEli Cohen1-0/+4
Avoid calling mlx5_esw_modify_vport_rate() if qos is not enabled and avoid unnecessary syndrome messages from firmware. Fixes: fcb64c0f5640 ("net/mlx5: E-Switch, add ingress rate support") Signed-off-by: Eli Cohen <elic@nvidia.com> Reviewed-by: Roi Dayan <roid@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5: Disable QoS when min_rates on all VFs are zeroVladyslav Tarasiuk1-7/+8
Currently when QoS is enabled for VF and any min_rate is configured, the driver sets bw_share value to at least 1 and doesn’t allow to set it to 0 to make minimal rate unlimited. It means there is always a minimal rate configured for every VF, even if user tries to remove it. In order to make QoS disable possible, check whether all vports have configured min_rate = 0. If this is true, set their bw_share to 0 to disable min_rate limitations. Fixes: c9497c98901c ("net/mlx5: Add support for setting VF min rate") Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5: Clear bw_share upon VF disableVladyslav Tarasiuk1-0/+1
Currently, if user disables VFs with some min and max rates configured, they are cleared. But QoS data is not cleared and restored upon next VF enable placing limits on minimal rate for given VF, when user expects none. To match cleared vport->info struct with QoS-related min and max rates upon VF disable, clear vport->qos struct too. Fixes: 556b9d16d3f5 ("net/mlx5: Clear VF's configuration on disabling SRIOV") Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Reviewed-by: Moshe Shemesh <moshe@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5: Add handling of port type in rule deletionMichael Guralnik1-0/+7
Handle destruction of rules with port destination type to enable full destruction of flow. Without this handling of TX rules the deletion of these rules fails. Dmesg of flow destruction failure: [ 203.714146] mlx5_core 0000:00:0b.0: mlx5_cmd_check:753:(pid 342): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x144b7a) [ 210.547387] ------------[ cut here ]------------ [ 210.548663] refcount_t: decrement hit 0; leaking memory. [ 210.550651] WARNING: CPU: 4 PID: 342 at lib/refcount.c:31 refcount_warn_saturate+0x5c/0x110 [ 210.550654] Modules linked in: mlx5_ib mlx5_core ib_ipoib rdma_ucm rdma_cm iw_cm ib_cm ib_umad ib_uverbs ib_core [ 210.550675] CPU: 4 PID: 342 Comm: test Not tainted 5.8.0-rc2+ #116 [ 210.550678] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 [ 210.550680] RIP: 0010:refcount_warn_saturate+0x5c/0x110 [ 210.550685] Code: c6 d1 1b 01 00 0f 84 ad 00 00 00 5b 5d c3 80 3d b5 d1 1b 01 00 75 f4 48 c7 c7 20 d1 15 82 c6 05 a5 d1 1b 01 01 e8 a7 eb af ff <0f> 0b eb dd 80 3d 99 d1 1b 01 00 75 d4 48 c7 c7 c0 cf 15 82 c6 05 [ 210.550687] RSP: 0018:ffff8881642e77e8 EFLAGS: 00010282 [ 210.550691] RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000 [ 210.550694] RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffffed102c85ceef [ 210.550696] RBP: ffff888161720428 R08: ffffffff8124c10e R09: ffffed103243beae [ 210.550698] R10: ffff8881921df56b R11: ffffed103243bead R12: ffff8881841b4180 [ 210.550701] R13: ffff888161720428 R14: ffff8881616d0000 R15: ffff888161720380 [ 210.550704] FS: 00007fc27f025740(0000) GS:ffff888192000000(0000) knlGS:0000000000000000 [ 210.550706] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 210.550708] CR2: 0000557e4b41a6a0 CR3: 0000000002415004 CR4: 0000000000360ea0 [ 210.550711] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 210.550713] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 210.550715] Call Trace: [ 210.550717] mlx5_del_flow_rules+0x484/0x490 [mlx5_core] [ 210.550720] ? mlx5_cmd_set_fte+0xa80/0xa80 [mlx5_core] [ 210.550722] mlx5_ib_destroy_flow+0x17f/0x280 [mlx5_ib] [ 210.550724] uverbs_free_flow+0x4c/0x90 [ib_uverbs] [ 210.550726] destroy_hw_idr_uobject+0x41/0xb0 [ib_uverbs] [ 210.550728] uverbs_destroy_uobject+0xaa/0x390 [ib_uverbs] [ 210.550731] __uverbs_cleanup_ufile+0x129/0x1b0 [ib_uverbs] [ 210.550733] ? uverbs_destroy_uobject+0x390/0x390 [ib_uverbs] [ 210.550735] uverbs_destroy_ufile_hw+0x78/0x190 [ib_uverbs] [ 210.550737] ib_uverbs_close+0x36/0x140 [ib_uverbs] [ 210.550739] __fput+0x181/0x380 [ 210.550741] task_work_run+0x88/0xd0 [ 210.550743] do_exit+0x5f6/0x13b0 [ 210.550745] ? sched_clock_cpu+0x30/0x140 [ 210.550747] ? is_current_pgrp_orphaned+0x70/0x70 [ 210.550750] ? lock_downgrade+0x360/0x360 [ 210.550752] ? mark_held_locks+0x1d/0x90 [ 210.550754] do_group_exit+0x8a/0x140 [ 210.550756] get_signal+0x20a/0xf50 [ 210.550758] do_signal+0x8c/0xbe0 [ 210.550760] ? hrtimer_nanosleep+0x1d8/0x200 [ 210.550762] ? nanosleep_copyout+0x50/0x50 [ 210.550764] ? restore_sigcontext+0x320/0x320 [ 210.550766] ? __hrtimer_init+0xf0/0xf0 [ 210.550768] ? timespec64_add_safe+0x150/0x150 [ 210.550770] ? mark_held_locks+0x1d/0x90 [ 210.550772] ? lockdep_hardirqs_on_prepare+0x14c/0x240 [ 210.550774] __prepare_exit_to_usermode+0x119/0x170 [ 210.550776] do_syscall_64+0x65/0x300 [ 210.550778] ? trace_hardirqs_off+0x10/0x120 [ 210.550781] ? mark_held_locks+0x1d/0x90 [ 210.550783] ? asm_sysvec_apic_timer_interrupt+0xa/0x20 [ 210.550785] ? lockdep_hardirqs_on+0x112/0x190 [ 210.550787] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 210.550789] RIP: 0033:0x7fc27f1cd157 [ 210.550791] Code: Bad RIP value. [ 210.550793] RSP: 002b:00007ffd4db27ea8 EFLAGS: 00000246 ORIG_RAX: 0000000000000023 [ 210.550798] RAX: fffffffffffffdfc RBX: ffffffffffffff80 RCX: 00007fc27f1cd157 [ 210.550800] RDX: 00007fc27f025740 RSI: 00007ffd4db27eb0 RDI: 00007ffd4db27eb0 [ 210.550803] RBP: 0000000000000016 R08: 0000000000000000 R09: 000000000000000e [ 210.550805] R10: 00007ffd4db27dc7 R11: 0000000000000246 R12: 0000000000400c00 [ 210.550808] R13: 00007ffd4db285f0 R14: 0000000000000000 R15: 0000000000000000 [ 210.550809] irq event stamp: 49399 [ 210.550812] hardirqs last enabled at (49399): [<ffffffff81172d36>] console_unlock+0x556/0x6f0 [ 210.550815] hardirqs last disabled at (49398): [<ffffffff81172897>] console_unlock+0xb7/0x6f0 [ 210.550818] softirqs last enabled at (48706): [<ffffffff81e0037b>] __do_softirq+0x37b/0x60c [ 210.550820] softirqs last disabled at (48697): [<ffffffff81c00e2f>] asm_call_on_stack+0xf/0x20 [ 210.550822] ---[ end trace ad18c0e6fa846454 ]--- [ 210.581862] mlx5_core 0000:00:0c.0: mlx5_destroy_flow_table:2132:(pid 342): Flow table 262150 wasn't destroyed, refcount > 1 Fixes: a7ee18bdee83 ("RDMA/mlx5: Allow creating a matcher for a NIC TX flow table") Signed-off-by: Michael Guralnik <michaelgur@nvidia.com> Reviewed-by: Mark Bloch <mbloch@nvidia.com> Reviewed-by: Maor Gottlieb <maorg@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5e: Fix check if netdev is bond slaveMaor Dickman1-1/+1
Bond events handler uses bond_slave_get_rtnl to check if net device is bond slave. bond_slave_get_rtnl return the rcu rx_handler pointer from the netdev which exists for bond slaves but also exists for devices that are attached to linux bridge so using it as indication for bond slave is wrong. Fix by using netif_is_lag_port instead. Fixes: 7e51891a237f ("net/mlx5e: Use netdev events to set/del egress acl forward-to-vport rule") Signed-off-by: Maor Dickman <maord@nvidia.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5e: Fix IPsec packet drop by mlx5e_tc_update_skbHuy Nguyen4-13/+16
Both TC and IPsec crypto offload use metadata_regB to store private information. Since TC does not use bit 31 of regB, IPsec will use bit 31 as the IPsec packet marker. The IPsec's regB usage is changed to: Bit31: IPsec marker Bit30-24: IPsec syndrome Bit23-0: IPsec obj id Fixes: b2ac7541e377 ("net/mlx5e: IPsec: Add Connect-X IPsec Rx data path offload") Signed-off-by: Huy Nguyen <huyn@mellanox.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Ariel Levkovich <lariel@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5e: Set IPsec WAs only in IP's non checksum partial case.Huy Nguyen1-7/+6
The IP's checksum partial still requires L4 csum flag on Ethernet WQE. Make the IPsec WAs only for the IP's non checksum partial case (for example icmd packet) Fixes: 5be019040cb7 ("net/mlx5e: IPsec: Add Connect-X IPsec Tx data path offload") Signed-off-by: Huy Nguyen <huyn@mellanox.com> Reviewed-by: Raed Salem <raeds@nvidia.com> Reviewed-by: Alaa Hleihel <alaa@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net/mlx5e: Fix refcount leak on kTLS RX resyncMaxim Mikityanskiy1-5/+8
On resync, the driver calls inet_lookup_established (__inet6_lookup_established) that increases sk_refcnt of the socket. To decrease it, the driver set skb->destructor to sock_edemux. However, it didn't work well, because the TCP stack also sets this destructor for early demux, and the refcount gets decreased only once, while increased two times (in mlx5e and in the TCP stack). It leads to a socket leak, a TLS context leak, which in the end leads to calling tls_dev_del twice: on socket close and on driver unload, which in turn leads to a crash. This commit fixes the refcount leak by calling sock_gen_put right away after using the socket, thus fixing all the subsequent issues. Fixes: 0419d8c9d8f8 ("net/mlx5e: kTLS, Add kTLS RX resync support") Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2020-11-17net: hns3: rename gl_adapt_enable in struct hns3_enet_coalesceHuazhong Tan3-11/+11
Besides GL(Gap Limiting), QL(Quantity Limiting) can be modified dynamically when DIM is supported. So rename gl_adapt_enable as adapt_enable in struct hns3_enet_coalesce. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net: hns3: add support for 1us unit GL configurationHuazhong Tan3-4/+31
For device whose version is above V3(include V3), the GL configuration can set as 1us unit, so adds support for configuring this field. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net: hns3: add support for querying maximum value of GLHuazhong Tan8-7/+38
For maintainability and compatibility, add support for querying the maximum value of GL. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net: hns3: add support for configuring interrupt quantity limitingHuazhong Tan5-18/+105
QL(quantity limiting) means that hardware supports the interrupt coalesce based on the frame quantity. QL can be configured when int_ql_max in device's specification is non-zero, so add support to configure it. Also, rename two coalesce init function to fit their purpose. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net: ftgmac100: Fix crash when removing driverJoel Stanley1-0/+4
When removing the driver we would hit BUG_ON(!list_empty(&dev->ptype_specific)) in net/core/dev.c due to still having the NC-SI packet handler registered. # echo 1e660000.ethernet > /sys/bus/platform/drivers/ftgmac100/unbind ------------[ cut here ]------------ kernel BUG at net/core/dev.c:10254! Internal error: Oops - BUG: 0 [#1] SMP ARM CPU: 0 PID: 115 Comm: sh Not tainted 5.10.0-rc3-next-20201111-00007-g02e0365710c4 #46 Hardware name: Generic DT based system PC is at netdev_run_todo+0x314/0x394 LR is at cpumask_next+0x20/0x24 pc : [<806f5830>] lr : [<80863cb0>] psr: 80000153 sp : 855bbd58 ip : 00000001 fp : 855bbdac r10: 80c03d00 r9 : 80c06228 r8 : 81158c54 r7 : 00000000 r6 : 80c05dec r5 : 80c05d18 r4 : 813b9280 r3 : 813b9054 r2 : 8122c470 r1 : 00000002 r0 : 00000002 Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 85514008 DAC: 00000051 Process sh (pid: 115, stack limit = 0x7cb5703d) ... Backtrace: [<806f551c>] (netdev_run_todo) from [<80707eec>] (rtnl_unlock+0x18/0x1c) r10:00000051 r9:854ed710 r8:81158c54 r7:80c76bb0 r6:81158c10 r5:8115b410 r4:813b9000 [<80707ed4>] (rtnl_unlock) from [<806f5db8>] (unregister_netdev+0x2c/0x30) [<806f5d8c>] (unregister_netdev) from [<805a8180>] (ftgmac100_remove+0x20/0xa8) r5:8115b410 r4:813b9000 [<805a8160>] (ftgmac100_remove) from [<805355e4>] (platform_drv_remove+0x34/0x4c) Fixes: bd466c3fb5a4 ("net/faraday: Support NCSI mode") Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201117024448.1170761-1-joel@jms.id.au Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17net: b44: fix error return code in b44_init_one()Zhang Changzhong1-1/+2
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 39a6f4bce6b4 ("b44: replace the ssb_dma API with the generic DMA API") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Link: https://lore.kernel.org/r/1605582131-36735-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17lan743x: replace devicetree phy parse code with library functionSven Van Asbroeck2-28/+8
The code in this driver which parses the devicetree to determine the phy/fixed link setup, can be replaced by a single library function: of_phy_get_and_connect(). Behaviour is identical, except that the library function will complain when 'phy-connection-type' is omitted, instead of blindly using PHY_INTERFACE_MODE_NA, which would result in an invalid phy configuration. The library function no longer brings out the exact phy_mode, but the driver doesn't need this, because phy_interface_is_rgmii() queries the phydev directly. Remove 'phy_mode' from the private adapter struct. While we're here, log info about the attached phy on connect, this is useful because the phy type and connection method is now fully configurable via the devicetree. Tested on a lan7430 chip with built-in phy. Verified that adding fixed-link/phy-connection-type in the devicetree results in a fixed-link setup. Used ethtool to verify that the devicetree settings are used. Tested-by: Sven Van Asbroeck <thesven73@gmail.com> # lan7430 Signed-off-by: Sven Van Asbroeck <thesven73@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20201116170155.26967-1-TheSven73@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17qed: fix error return code in qed_iwarp_ll2_start()Zhang Changzhong1-3/+9
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 469981b17a4f ("qed: Add unaligned and packed packet processing") Fixes: fcb39f6c10b2 ("qed: Add mpa buffer descriptors for storing and processing mpa fpdus") Fixes: 1e28eaad07ea ("qed: Add iWARP support for fpdu spanned over more than two tcp packets") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Michal Kalderon <michal.kalderon@marvell.com> Link: https://lore.kernel.org/r/1605532033-27373-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17r8169: remove nr_frags argument from rtl_tx_slots_availHeiner Kallweit1-9/+6
The only time when nr_frags isn't SKB_MAX_FRAGS is when entering rtl8169_start_xmit(). However we can use SKB_MAX_FRAGS also here because when queue isn't stopped there should always be room for MAX_SKB_FRAGS + 1 descriptors. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/3d1f2ad7-31d5-2cac-4f4a-394f8a3cab63@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17bnxt_en: Avoid unnecessary NVM_GET_DEV_INFO cmd error log on VFs.Vasundhara Volam1-0/+3
VFs do not have access permissions to issue NVM_GET_DEV_INFO firmware command. Fixes: 4933f6753b50 ("bnxt_en: Add bnxt_hwrm_nvm_get_dev_info() to query NVM info.") Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2020-11-17bnxt_en: Fix counter overflow logic.Michael Chan1-0/+1
bnxt_add_one_ctr() adds a hardware counter to a software counter and adjusts for the hardware counter wraparound against the mask. The logic assumes that the hardware counter is always smaller than or equal to the mask. This assumption is mostly correct. But in some cases if the firmware is older and does not provide the accurate mask, the driver can use a mask that is smaller than the actual hardware mask. This can cause some extra carry bits to be added to the software counter, resulting in counters that far exceed the actual value. Fix it by masking the hardware counter with the mask passed into bnxt_add_one_ctr(). Fixes: fea6b3335527 ("bnxt_en: Accumulate all counters.") Reviewed-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 03:20:17 +0300