- 19 Apr, 2021 40 commits
-
-
Radu Pirea (NXP OSS) authored
Add driver for tja1103 driver and for future NXP C45 PHYs. Signed-off-by:
Radu Pirea (NXP OSS) <radu-nicolae.pirea@oss.nxp.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Radu Pirea (NXP OSS) authored
Add generic PMA suspend and resume callback functions for C45 PHYs. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vadym Kochan authored
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:
-
Wong Vee Khee authored
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: bba2556e ("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 authored
Thomas Bogendoerfer says: ==================== net: Korina improvements While converting Mikrotik RB532 support to use device tree I stumbled over the korina ethernet driver, which used way too many MIPS specific hacks. This series cleans this all up and adds support for device tree. Changes in v6: - remove korina from resource names and adapt DT binding to it - removed superfluous braces around of_get_mac_address Changes in v5: - fixed email address in binding document, which prevented sending it Changes in v4: - improve error returns in mdio_read further - added clock name and improved clk handling - fixed binding errors Changes in v3: - use readl_poll_timeout_atomic in mdio_wait - return -ETIMEDOUT, if mdio_wait failed - added DT binding and changed name to idt,3243x-emac - fixed usage of of_get_mac_address for net-next Changes in v2: - added device tree support to get rid of idt_cpu_freq - fixed compile test on 64bit archs - fixed descriptor current address handling by storing/using mapped dma addresses (dma controller modifies current address) ==================== Signed-off-by: -
Thomas Bogendoerfer authored
Add device tree bindings for ethernet controller integrated into IDT 79RC3243x SoCs. Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Thomas Bogendoerfer authored
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 authored
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 authored
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 authored
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 authored
Instead of messing with MIPS specific macros use DMA API for mapping descriptors and skbs. Reviewed-by:
-
Thomas Bogendoerfer authored
Remove helpers, which are only used in one call site. Reviewed-by:
-
Thomas Bogendoerfer authored
Descriptors are mapped uncached so there is no need to do any cache handling for them. Reviewed-by:
-
Thomas Bogendoerfer authored
Simplify probe/remove code by using devm_ functions. Reviewed-by:
-
Thomas Bogendoerfer authored
Fixed MDIO functions to work reliable and not just by accident. Signed-off-by:
-
David S. Miller authored
Pablo Neira Ayuso says: ==================== mtk_ppe_offload fixes A few incremental fixes for the initial flowtable offload support and this driver: 1) Fix undefined reference to `dsa_port_from_netdev' due to missing dependencies in Kconfig, reported by Kbuild robot. 2) Missing mutex to serialize flow events via workqueue to the driver. 3) Handle FLOW_ACTION_VLAN_POP tag action. ==================== Signed-off-by: -
Pablo Neira Ayuso authored
Do not hit EOPNOTSUPP when flowtable offload provides a VLAN pop action. Fixes: efce49df ("netfilter: flowtable: add vlan pop action offload support") Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pablo Neira Ayuso authored
Patch 2ed37183 ("netfilter: flowtable: separate replace, destroy and stats to different workqueues") splits the workqueue per event type. Add a mutex to serialize updates. Fixes: 502e84e2 ("net: ethernet: mtk_eth_soc: add flow offloading support") Reported-by:
Frank Wunderlich <frank-w@public-files.de> Signed-off-by:
-
Pablo Neira Ayuso authored
Caused by: CONFIG_NET_DSA=m CONFIG_NET_MEDIATEK_SOC=y mtk_ppe_offload.c:undefined reference to `dsa_port_from_netdev' Fixes: 502e84e2 ("net: ethernet: mtk_eth_soc: add flow offloading support") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-nextDavid S. Miller authored
Pablo Neira Ayuso says: ==================== Netfilter updates for net-next The following patchset contains Netfilter updates for net-next: 1) Add vlan match and pop actions to the flowtable offload, patches from wenxu. 2) Reduce size of the netns_ct structure, which itself is embedded in struct net Make netns_ct a read-mostly structure. Patches from Florian Westphal. 3) Add FLOW_OFFLOAD_XMIT_UNSPEC to skip dst check from garbage collector path, as required by the tc CT action. From Roi Dayan. 4) VLAN offload fixes for nftables: Allow for matching on both s-vlan and c-vlan selectors. Fix match of VLAN id due to incorrect byteorder. Add a new routine to properly populate flow dissector ethertypes. 5) Missing keys in ip{6}_route_me_harder() results in incorrect routes. This includes an update for selftest infra. Patches from Ido Schimmel. 6) Add counter hardware offload support through FLOW_CLS_STATS. ==================== Signed-off-by: -
Alexey Dobriyan authored
Taking address of a function argument directly works just fine. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
-
DENG Qingfang authored
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: 502e84e2 ("net: ethernet: mtk_eth_soc: add flow offloading support") Signed-off-by:
DENG Qingfang <dqfext@gmail.com> Tested-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: misc updates for -next This series includes some misc updates for the HNS3 ethernet driver. ==================== Signed-off-by: -
Huazhong Tan authored
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:
-
Huazhong Tan authored
Modify some inappropriate spaces in comments of struct hlcgevf_tqp_stats. Signed-off-by:
-
Huazhong Tan authored
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:
-
Randy Dunlap authored
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: 8a3b7a25 ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Flow control for NXP ENETC This patch series contains logic for enabling the lossless mode on the RX rings of the ENETC, and the PAUSE thresholds on the internal FIFO memory. During testing it was found that, with the default FIFO configuration, a sender which isn't persuaded by our PAUSE frames and keeps sending will cause some MAC RX frame errors. To mitigate this, we need to ensure that the FIFO never runs completely full, so we need to fix up a setting that was supposed to be configured well out of reset. Unfortunately this requires the addition of a new mini-driver. ==================== Signed-off-by: -
Vladimir Oltean authored
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:
-
Vladimir Oltean authored
Add a node describing the address in the SoC memory space for the IERB. Signed-off-by:
-
Vladimir Oltean authored
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 authored
Mention the required compatible string and base address for the Integrated Endpoint Register Block node. Signed-off-by:
-
Vladimir Oltean authored
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:
-
Gustavo A. R. Silva authored
Fix the following out-of-bounds warning: net/ethtool/ioctl.c:492:2: warning: 'memcpy' offset [49, 84] from the object at 'link_usettings' is out of the bounds of referenced subobject 'base' with type 'struct ethtool_link_settings' at offset 0 [-Warray-bounds] The problem is that the original code is trying to copy data into a some struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &link_usettings.base. Fix this by directly using &link_usettings and _from_ as destination and source addresses, instead. This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109Reported-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Signed-off-by:
-
Dexuan Cui authored
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:
Shachar Raindel <shacharr@microsoft.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Taehee Yoo authored
Some prototypes are unnecessary, so delete it. Signed-off-by:
Taehee Yoo <ap420073@gmail.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== nexthop: Support large scale nexthop flushing Patch #1 fixes a day-one bug in the nexthop code and allows "ip nexthop flush" to work correctly with large number of nexthops that do not fit in a single-part dump. Patch #2 adds a test case. Targeting at net-next since this use case never worked, the flow is pretty obscure and such a large number of nexthops is unlikely to be used in any real-world scenario. Tested with fib_nexthops.sh: Tests passed: 219 Tests failed: 0 ==================== Signed-off-by: -
Ido Schimmel authored
Test that all the nexthops are flushed when a multi-part nexthop dump is required for the flushing. Without previous patch: # ./fib_nexthops.sh TEST: Large scale nexthop flushing [FAIL] With previous patch: # ./fib_nexthops.sh TEST: Large scale nexthop flushing [ OK ] Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Ido Schimmel authored
Currently, a multi-part nexthop dump is restarted based on the number of nexthops that have been dumped so far. This can result in a lot of nexthops not being dumped when nexthops are simultaneously deleted: # ip nexthop | wc -l 65536 # ip nexthop flush Dump was interrupted and may be inconsistent. Flushed 36040 nexthops # ip nexthop | wc -l 29496 Instead, restart the dump based on the nexthop identifier (fixed number) of the last successfully dumped nexthop: # ip nexthop | wc -l 65536 # ip nexthop flush Dump was interrupted and may be inconsistent. Flushed 65536 nexthops # ip nexthop | wc -l 0 Reported-by:
Maksym Yaremchuk <maksymy@nvidia.com> Tested-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-2021-04-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== wireless-drivers-next patches for v5.13 Second set of patches for v5.13. A lot of iwlwifi and mt76 patches this time, and also smaller features and fixes all over. mt76 * mt7915/mt7615 decapsulation offload support * threaded NAPI support * new device IDs * mt7921 device reset support * rx timestamp support iwlwifi * passive scan support for 6GHz * new hardware support wilc1000 * CRC support for SPI bus ==================== Signed-off-by:
-
