summaryrefslogtreecommitdiff
path: root/drivers/net/ethernet
AgeCommit message (Collapse)AuthorFilesLines
2021-04-20net/mlx5: DR, Set flex parser for TNL_MPLS dynamicallyYevgeny Kliteynik7-20/+262
Query the flex_parser id that's intended for TNL_MPLS and use an appropriate flex parser for MPLS over UDP/GRE. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Add support for matching on geneve TLV optionYevgeny Kliteynik7-4/+107
Enable matching on tunnel geneve TLV option using the flex parser. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Set STEv0 ICMP flex parser dynamicallyYevgeny Kliteynik6-52/+43
Set the flex parser ID dynamicly for ICMP instead of relying on hardcoded values. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Add support for dynamic flex parserYevgeny Kliteynik7-1/+279
Flex parser is a HW parser that can support protocols that are not natively supported by the HCA, such as Geneve (TLV options) and GTP-U. There are 8 such parsers, and each of them can be assigned to parse a specific set of protocols. This patch adds misc4 match params which allows using a correct flex parser that was programmed to the required protocol. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Remove protocol-specific flex_parser_3 definitionsMuhammad Sammar3-26/+27
Remove MPLS specific fields from flex parser 3 layout. Flex parser can be used for multiple protocols and should not be hardcoded to a specific type. Signed-off-by: Muhammad Sammar <muhammads@nvidia.com> Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: E-Switch, Improve error messages in term table creationYevgeny Kliteynik1-6/+8
Add error code to the error messages and removed duplicated message: if termination table creation failed, we already get an error message in mlx5_eswitch_termtbl_create, so no need for the additional error print in the calling function. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Fix SQ/RQ in doorbell bitmaskYevgeny Kliteynik1-1/+1
QP doorbell size is 16 bits. Fixing sw steering's QP doorbel bitmask, which had 20 bits. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5: DR, Rename an argument in dr_rdma_segmentsYevgeny Kliteynik1-4/+4
Rename the argument to better reflect that the meaning is not number of records, but wheather or not we should ring the dorbell. Signed-off-by: Yevgeny Kliteynik <kliteyn@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5e: RX, Add checks for calculated Striding RQ attributesTariq Toukan3-40/+71
Striding RQ attributes below are mutually dependent. An unaware change to one might take the others out of the valid range derived by the HW caps: - The MPWQE size in bytes - The number of strides in a MPWQE - The stride size Add checks to verify they are valid and comply to the HW spec and SW assumptions/requirements. This is not a fix, no particular issue exists today. Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5e: Fix possible non-initialized struct usageVladyslav Tarasiuk2-4/+15
If mlx5e_devlink_port_register() fails, driver may try to register devlink health TX and RX reporters on non-registered devlink port. Instead, create health reporters only if mlx5e_devlink_port_register() does not fail. And destroy reporters only if devlink_port is registered. Also, change mlx5e_get_devlink_port() behavior and return NULL in case port is not registered to replicate devlink's wrapper when ndo is not implemented. Signed-off-by: Vladyslav Tarasiuk <vladyslavt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20net/mlx5e: Fix lost changes during code movementsTariq Toukan1-2/+3
The changes done in commit [1] were missed by the code movements done in [2], as they were developed in ~parallel. Here we re-apply them. [1] commit e4484d9df500 ("net/mlx5e: Enable striding RQ for Connect-X IPsec capable devices") [2] commit b3a131c2a160 ("net/mlx5e: Move params logic into its dedicated file") Fixes: b3a131c2a160 ("net/mlx5e: Move params logic into its dedicated file") Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Aya Levin <ayal@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
2021-04-20bnxt: add more ethtool standard statsJakub Kicinski1-0/+6
Michael suggest a few more stats we can expose. $ ethtool -S eth0 --groups eth-mac Standard stats for eth0: eth-mac-FramesTransmittedOK: 902623288966 eth-mac-FramesReceivedOK: 28727667047 eth-mac-FrameCheckSequenceErrors: 1 eth-mac-AlignmentErrors: 0 eth-mac-OutOfRangeLengthField: 0 $ ethtool -S eth0 | grep '\(fcs\|align\|oor\)' rx_fcs_err_frames: 1 rx_align_err_frames: 0 tx_fcs_err_frames: 0 Suggested-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: marvell: prestera: add support for AC3X 98DX3265 deviceVadym Kochan1-0/+1
Add PCI match for AC3X 98DX3265 device which is supported by the current driver and firmware. Signed-off-by: Vadym Kochan <vkochan@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: stmmac: fix memory leak during driver probeWong Vee Khee1-0/+2
On driver probe, kmemleak reported the following memory leak which was due to allocated bitmap that was not being freed in stmmac_dvr_probe(). unreferenced object 0xffff9276014b13c0 (size 8): comm "systemd-udevd", pid 2143, jiffies 4294681112 (age 116.720s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [<00000000c51e34b2>] stmmac_dvr_probe+0x1c0/0x440 [stmmac] [<00000000b530eb41>] intel_eth_pci_probe.cold+0x2b/0x14e [dwmac_intel] [<00000000b10f8929>] pci_device_probe+0xd2/0x150 [<00000000fb254c74>] really_probe+0xf8/0x410 [<0000000034128a59>] driver_probe_device+0x5d/0x150 [<00000000016104d5>] device_driver_attach+0x53/0x60 [<00000000cb18cd07>] __driver_attach+0x96/0x140 [<00000000da9ffd5c>] bus_for_each_dev+0x7a/0xc0 [<00000000af061a88>] bus_add_driver+0x184/0x1f0 [<000000008be5c1c5>] driver_register+0x6c/0xc0 [<0000000052b18a9e>] do_one_initcall+0x4d/0x210 [<00000000154d4f07>] do_init_module+0x5c/0x230 [<000000009b648d09>] load_module+0x2a5a/0x2d40 [<000000000d86b76d>] __do_sys_finit_module+0xb5/0x120 [<000000002b0cef95>] do_syscall_64+0x33/0x40 [<0000000067b45bbb>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy") Cc: Ong Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Make driver COMPILE_TESTableThomas Bogendoerfer2-12/+239
Move structs/defines for ethernet/dma register into driver, since they are only used for this driver and remove any MIPS specific includes. This makes it possible to COMPILE_TEST the driver. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Get mdio input clock via common clock frameworkThomas Bogendoerfer1-6/+15
With device tree clock is provided via CCF. For non device tree use a maximum clock value to not overclock the PHY. The non device tree usage will go away after platform is converted to DT. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Add support for device treeThomas Bogendoerfer1-7/+25
If there is no mac address passed via platform data try to get it via device tree and fall back to a random mac address, if all fail. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Only pass mac address via platform dataThomas Bogendoerfer1-5/+6
Get rid of access to struct korina_device by just passing the mac address via platform data and use drvdata for passing netdev to remove function. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Use DMA APIThomas Bogendoerfer1-60/+98
Instead of messing with MIPS specific macros use DMA API for mapping descriptors and skbs. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Remove nested helpersThomas Bogendoerfer1-25/+3
Remove helpers, which are only used in one call site. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Remove not needed cache flushesThomas Bogendoerfer1-6/+0
Descriptors are mapped uncached so there is no need to do any cache handling for them. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Use devres functionsThomas Bogendoerfer1-43/+21
Simplify probe/remove code by using devm_ functions. Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: korina: Fix MDIO functionsThomas Bogendoerfer2-19/+38
Fixed MDIO functions to work reliable and not just by accident. Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: ethernet: mtk_eth_soc: handle VLAN pop actionPablo Neira Ayuso1-0/+2
Do not hit EOPNOTSUPP when flowtable offload provides a VLAN pop action. Fixes: efce49dfe6a8 ("netfilter: flowtable: add vlan pop action offload support") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: ethernet: mtk_eth_soc: missing mutexPablo Neira Ayuso1-5/+14
Patch 2ed37183abb7 ("netfilter: flowtable: separate replace, destroy and stats to different workqueues") splits the workqueue per event type. Add a mutex to serialize updates. Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support") Reported-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: ethernet: mtk_eth_soc: fix undefined reference to `dsa_port_from_netdev'Pablo Neira Ayuso1-0/+1
Caused by: CONFIG_NET_DSA=m CONFIG_NET_MEDIATEK_SOC=y mtk_ppe_offload.c:undefined reference to `dsa_port_from_netdev' Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: ethernet: ixp4xx: Set the DMA masks explicitlyLinus Walleij1-1/+4
The former fix only papered over the actual problem: the ethernet core expects the netdev .dev member to have the proper DMA masks set, or there will be BUG_ON() triggered in kernel/dma/mapping.c. Fix this by simply copying dma_mask and dma_mask_coherent from the parent device. Fixes: e45d0fad4a5f ("net: ethernet: ixp4xx: Use parent dev for DMA pool") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: ethernet: mediatek: fix a typo bug in flow offloadingDENG Qingfang1-1/+1
Issue was traffic problems after a while with increased ping times if flow offload is active. It turns out that key_offset with cookie is needed in rhashtable_params but was re-assigned to head_offset. Fix the assignment. Fixes: 502e84e2382d ("net: ethernet: mtk_eth_soc: add flow offloading support") Signed-off-by: DENG Qingfang <dqfext@gmail.com> Tested-by: Frank Wunderlich <frank-w@public-files.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: hns3: change the value of the SEPARATOR_VALUE macro in hclgevf_main.cHuazhong Tan1-1/+1
The SEPARATOR_VALUE macro is used as separator when getting the register value, but the value of this macro is different between pf and vf, it is a bit confusing for the user, so synchronize the value of vf with pf. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: hns3: cleanup inappropriate spaces in struct hlcgevf_tqp_statsHuazhong Tan1-2/+2
Modify some inappropriate spaces in comments of struct hlcgevf_tqp_stats. Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: hns3: remove a duplicate pf reset countingHuazhong Tan1-2/+0
When enter suspend mode the counter of pf reset will be increased twice, since both hclge_prepare_general() and hclge_prepare_wait() increase this counter. So remove the duplicate counting in hclge_prepare_general(). Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: xilinx: drivers need/depend on HAS_IOMEMRandy Dunlap1-0/+3
kernel test robot reports build errors in 3 Xilinx ethernet drivers. They all use ioremap functions that are only available when HAS_IOMEM is set/enabled. If it is not enabled, they all have build errors, so make these 3 drivers depend on HAS_IOMEM. ld: drivers/net/ethernet/xilinx/xilinx_emaclite.o: in function `xemaclite_of_probe': xilinx_emaclite.c:(.text+0x9fc): undefined reference to `devm_ioremap_resource' ld: drivers/net/ethernet/xilinx/xilinx_axienet_main.o: in function `axienet_probe': xilinx_axienet_main.c:(.text+0x942): undefined reference to `devm_ioremap_resource' ld: drivers/net/ethernet/xilinx/ll_temac_main.o: in function `temac_probe': ll_temac_main.c:(.text+0x1283): undefined reference to `devm_platform_ioremap_resource_byname' ld: ll_temac_main.c:(.text+0x13ad): undefined reference to `devm_of_iomap' ld: ll_temac_main.c:(.text+0x162e): undefined reference to `devm_platform_ioremap_resource' Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Cc: Gary Guo <gary@garyguo.net> Cc: Zhang Changzhong <zhangchangzhong@huawei.com> Cc: Andre Przywara <andre.przywara@arm.com> Cc: stable@vger.kernel.org Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: enetc: add support for flow controlVladimir Oltean3-2/+85
In the ENETC receive path, a frame received by the MAC is first stored in a 256KB 'FIFO' memory, then transferred to DRAM when enqueuing it to the RX ring. The FIFO is a shared resource for all ENETC ports, but every port keeps track of its own memory utilization, on RX and on TX. There is a setting for RX rings through which they can either operate in 'lossy' mode (where the lack of a free buffer causes an immediate discard of the frame) or in 'lossless' mode (where the lack of a free buffer in the ring makes the frame stay longer in the FIFO). In turn, when the memory utilization of the FIFO exceeds a certain margin, the MAC can be configured to emit PAUSE frames. There is enough FIFO memory to buffer up to 3 MTU-sized frames per RX port while not jeopardizing the other use cases (jumbo frames), and also not consume bytes from the port TX allocations. Also, 3 MTU-sized frames worth of memory is enough to ensure zero loss for 64 byte packets at 1G line rate. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: enetc: add a mini driver for the Integrated Endpoint Register BlockVladimir Oltean5-1/+221
The NXP ENETC is a 4-port Ethernet controller which 'smells' to operating systems like 4 distinct PCIe PFs with SR-IOV, each PF having its own driver instance, but in fact there are some hardware resources which are shared between all ports, like for example the 256 KB SRAM FIFO between the MACs and the Host Transfer Agent which DMAs frames to DRAM. To hide the stuff that cannot be neatly exposed per port, the hardware designers came up with this idea of having a dedicated register block which is supposed to be populated by the bootloader, and contains everything configuration-related: MAC addresses, FIFO partitioning, etc. When a port is reset using PCIe Function Level Reset, its defaults are transferred from the IERB configuration. Most of the time, the settings made through the IERB are read-only in the port's memory space (if they are even visible), so they cannot be modified at runtime. Linux doesn't have any advanced FIFO partitioning requirements at all, but when reading through the hardware manual, it became clear that, even though there are many good 'recommendations' for default values, many of them were not actually put in practice on LS1028A. So we end up with a default configuration that: (a) does not have enough TX and RX byte credits to support the max MTU of 9600 (which the Linux driver claims already) properly (at full speed) (b) allows the FIFO to be overrun with RX traffic, potentially overwriting internal data structures. The last part sounds a bit catastrophic, but it isn't. Frames are supposed to transit the FIFO for a very short time, but they can actually accumulate there under 2 conditions: (a) there is very severe congestion on DRAM memory, or (b) the RX rings visible to the operating system were configured for lossless operation, and they just ran out of free buffers to copy the frame to. This is what is used to put backpressure onto the MAC with flow control. So since ENETC has not supported flow control thus far, RX FIFO overruns were never seen with Linux. But with the addition of flow control, we should configure some registers to prevent this from happening. What we are trying to protect against are bad actors which continue to send us traffic despite the fact that we have signaled a PAUSE condition. Of course we can't be lossless in that case, but it is best to configure the FIFO to do tail dropping rather than letting it overrun. So in a nutshell, this driver is a fixup for all the IERB default values that should have been but aren't. The IERB configuration needs to be done _before_ the PFs are enabled. So every PF searches for the presence of the "fsl,ls1028a-enetc-ierb" node in the device tree, and if it finds it, it "registers" with the IERB, which means that it requests the IERB to fix up its default values. This is done through -EPROBE_DEFER. The IERB driver is part of the fsl_enetc module, but is technically a platform driver, since the IERB is a good old fashioned MMIO region, as opposed to ENETC ports which pretend to be PCIe devices. The driver was already configuring ENETC_PTXMBAR (FIFO allocation for TX) because due to an omission, TXMBAR is a read/write register in the PF memory space. But the manual is quite clear that the formula for this should depend upon the TX byte credits (TXBCR). In turn, the TX byte credits are only readable/writable through the IERB. So if we want to ensure that the TXBCR register also has a value that is correct and in line with TXMBAR, there is simply no way this can be done from the PF driver, access to the IERB is needed. I could have modified U-Boot to fix up the IERB values, but that is quite undesirable, as old U-Boot versions are likely to be floating around for quite some time from now. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: enetc: create a common enetc_pf_to_port helperVladimir Oltean2-10/+22
Even though ENETC interfaces are exposed as individual PCIe PFs with their own driver instances, the ENETC is still fundamentally a multi-port Ethernet controller, and some parts of the IP take a port number (as can be seen in the PSFP implementation). Create a common helper that can be used outside of the TSN code for retrieving the ENETC port number based on the PF number. This is only correct for LS1028A, the only Linux-capable instantiation of ENETC thus far. Note that ENETC port 3 is PF 6. The TSN code did not care about this because ENETC port 3 does not support TSN, so the wrong mapping done by enetc_get_port for PF 6 could have never been hit. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-20net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)Dexuan Cui14-0/+6153
Add a VF driver for Microsoft Azure Network Adapter (MANA) that will be available in the future. Co-developed-by: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com> Co-developed-by: Shachar Raindel <shacharr@microsoft.com> Signed-off-by: Shachar Raindel <shacharr@microsoft.com> Signed-off-by: Dexuan Cui <decui@microsoft.com> Reviewed-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-19RDMA/bnxt_re: Create direct symbol link between bnxt modulesLeon Romanovsky3-3/+1
Convert indirect probe call to its direct equivalent to create a symbol link between RDMA and netdev modules. This will give us an ability to remove custom module reference counting that doesn't belong to the driver. Link: https://lore.kernel.org/r/20210401065715.565226-3-leon@kernel.org Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Acked-By: Devesh Sharma <devesh.sharma@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-04-18r8169: keep pause settings on interface down/up cycleHeiner Kallweit1-5/+9
Currently, if the user changes the pause settings, the default settings will be restored after an interface down/up cycle, and also when resuming from suspend. This doesn't seem to provide the best user experience. Change this to keep user settings, and just ensure that in jumbo mode pause is disabled. Small drawback: When switching back mtu from jumbo to non-jumbo then pause remains disabled (but user can enable it using ethtool). I think that's a not too common scenario and acceptable. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski13-212/+67
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c - keep the ZC code, drop the code related to reinit net/bridge/netfilter/ebtables.c - fix build after move to net_generic Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2021-04-17net: enetc: apply the MDIO workaround for XDP_REDIRECT tooVladimir Oltean1-0/+4
Described in fd5736bf9f23 ("enetc: Workaround for MDIO register access issue") is a workaround for a hardware bug that requires a register access of the MDIO controller to never happen concurrently with a register access of a port PF. To avoid that, a mutual exclusion scheme with rwlocks was implemented - the port PF accessors are the 'read' side, and the MDIO accessors are the 'write' side. When we do XDP_REDIRECT between two ENETC interfaces, all is fine because the MDIO lock is already taken from the NAPI poll loop. But when the ingress interface is not ENETC, just the egress is, the MDIO lock is not taken, so we might access the port PF registers concurrently with MDIO, which will make the link flap due to wrong values returned from the PHY. To avoid this, let's just slap an enetc_lock_mdio/enetc_unlock_mdio at the beginning and ending of enetc_xdp_xmit. The fact that the MDIO lock is designed as a rwlock is important here, because the read side is reentrant (that is one of the main reasons why we chose it). Usually, the way we benefit of its reentrancy is by running the data path concurrently on both CPUs, but in this case, we benefit from the reentrancy by taking the lock even when the lock is already taken (and that's the situation where ENETC is both the ingress and the egress interface for XDP_REDIRECT, which was fine before and still is fine now). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: fix buffer leaks with XDP_TX enqueue rejectionsVladimir Oltean1-4/+12
If the TX ring is congested, enetc_xdp_tx() returns false for the current XDP frame (represented as an array of software BDs). This array of software TX BDs is constructed in enetc_rx_swbd_to_xdp_tx_swbd from software BDs freshly cleaned from the RX ring. The issue is that we scrub the RX software BDs too soon, more precisely before we know that we can enqueue the TX BDs successfully into the TX ring. If we can't enqueue them (and enetc_xdp_tx returns false), we call enetc_xdp_drop which attempts to recycle the buffers held by the RX software BDs. But because we scrubbed those RX BDs already, two things happen: (a) we leak their memory (b) we populate the RX software BD ring with an all-zero rx_swbd structure, which makes the buffer refill path allocate more memory. enetc_refill_rx_ring -> if (unlikely(!rx_swbd->page)) -> enetc_new_page That is a recipe for fast OOM. Fixes: 7ed2bc80074e ("net: enetc: add support for XDP_TX") Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: handle the invalid XDP action the same way as XDP_DROPVladimir Oltean1-4/+3
When the XDP program returns an invalid action, we should free the RX buffer. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: use dedicated TX rings for XDPVladimir Oltean2-7/+40
It is possible for one CPU to perform TX hashing (see netdev_pick_tx) between the 8 ENETC TX rings, and the TX hashing to select TX queue 1. At the same time, it is possible for the other CPU to already use TX ring 1 for XDP (either XDP_TX or XDP_REDIRECT). Since there is no mutual exclusion between XDP and the network stack, we run into an issue because the ENETC TX procedure is not reentrant. The obvious approach would be to just make XDP take the lock of the network stack's TX queue corresponding to the ring it's about to enqueue in. For XDP_REDIRECT, this is quite straightforward, a lock at the beginning and end of enetc_xdp_xmit() should do the trick. But for XDP_TX, it's a bit more complicated. For one, we do TX batching all by ourselves for frames with the XDP_TX verdict. This is something we would like to keep the way it is, for performance reasons. But batching means that the network stack's lock should be kept from the first enqueued XDP_TX frame and until we ring the doorbell. That is mostly fine, except for cases when in the same NAPI loop we have mixed XDP_TX and XDP_REDIRECT frames. So if enetc_xdp_xmit() gets called while we are holding the lock from the RX NAPI, then bam, deadlock. The naive answer could be 'just flush the XDP_TX frames first, then release the network stack's TX queue lock, then call xdp_do_flush_map()'. But even xdp_do_redirect() is capable of flushing the batched XDP_REDIRECT frames, so unless we unlock/relock the TX queue around xdp_do_redirect(), there simply isn't any clean way to protect XDP_TX from concurrent network stack .ndo_start_xmit() on another CPU. So we need to take a different approach, and that is to reserve two rings for the sole use of XDP. We leave TX rings 0..ndev->real_num_tx_queues-1 to be handled by the network stack, and we pick them from the end of the priv->tx_ring array. We make an effort to keep the mapping done by enetc_alloc_msix() which decides which CPU handles the TX completions of which TX ring in its NAPI poll. So the XDP TX ring of CPU 0 is handled by TX ring 6, and the XDP TX ring of CPU 1 is handled by TX ring 7. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: increase TX ring sizeVladimir Oltean1-1/+1
Now that commit d6a2829e82cf ("net: enetc: increase RX ring default size") has increased the RX ring size, it is quite easy to congest the TX rings when the traffic is predominantly XDP_TX, as the RX ring is quite a bit larger than the TX one. Since we bit the bullet and did the expensive thing already (larger RX rings consume more memory pages), it seems quite foolish to keep the TX rings small. So make them equally sized with TX. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: remove unneeded xdp_do_flush_map()Vladimir Oltean1-5/+0
xdp_do_redirect already contains: -> dev_map_enqueue -> __xdp_enqueue -> bq_enqueue -> bq_xmit_all // if we have more than 16 frames So the logic from enetc will never be hit, because ENETC_DEFAULT_TX_WORK is 128. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: stop XDP NAPI processing when build_skb() failsVladimir Oltean1-2/+2
When the code path below fails: enetc_clean_rx_ring_xdp // XDP_PASS -> enetc_build_skb -> enetc_map_rx_buff_to_skb -> build_skb enetc_clean_rx_ring_xdp will 'break', but that 'break' instruction isn't strong enough to actually break the NAPI poll loop, just the switch/case statement for XDP actions. So we increment rx_frm_cnt and go to the next frames minding our own business. Instead let's do what the skb NAPI poll function does, and break the loop now, waiting for the memory pressure to go away. Otherwise the next calls to build_skb() are likely to fail too. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: recycle buffers for frames with RX errorsVladimir Oltean1-0/+2
When receiving a frame with errors, currently we do nothing with it (we don't construct an skb or an xdp_buff), we just exit the NAPI poll loop. Let's put the buffer back into the RX ring (similar to XDP_DROP). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: rename the buffer reuse helpersVladimir Oltean1-30/+24
enetc_put_xdp_buff has nothing to do with XDP, frankly, it is just a helper to populate the recycle end of the shadow RX BD ring (next_to_alloc) with a given buffer. On the other hand, enetc_put_rx_buff plays more tricks than its name would suggest. So let's rename enetc_put_rx_buff into enetc_flip_rx_buff to reflect the half-page buffer reuse tricks that it employs, and enetc_put_xdp_buff into enetc_put_rx_buff which suggests a more garden-variety operation. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17net: enetc: remove redundant clearing of skb/xdp_frame pointer in TX conf pathVladimir Oltean1-2/+0
Later in enetc_clean_tx_ring we have: /* Scrub the swbd here so we don't have to do that * when we reuse it during xmit */ memset(tx_swbd, 0, sizeof(*tx_swbd)); So these assignments are unnecessary. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-04-17Merge branch '1GbE' of ↵David S. Miller10-11/+478
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue Tony Nguyen says: ==================== 1GbE Intel Wired LAN Driver Updates 2021-04-16 This series contains updates to igb and igc drivers. Ederson adjusts Tx buffer distributions in Qav mode to improve TSN-aware traffic for igb. He also enable PPS support and auxiliary PHC functions for igc. Grzegorz checks that the MTA register was properly written and retries if not for igb. Sasha adds reporting of EEE low power idle counters to ethtool and fixes a return value being overwritten through looping for igc. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-08 06:06:12 +0300