- 27 Jul, 2019 12 commits
-
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: improve HW csum and TSO handling This series: - delegates more tasks from the driver to the core - enables HW csum and TSO per default - copies quirks for buggy chip versions from vendor driver ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Enable HW csum and TSO per default except on known buggy chip versions. Realtek confirmed that RTL8168evl has a HW issue with TSO. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
The loop in r8169_csum_workaround is called only if in msdn_giant_send_check a copy of the skb header needs to be made and we don't have enough memory. Let's simply drop the packet in that case so that we can remove r8169_csum_workaround. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Implement callback ndo_features_check and move all feature checks there. This will allow us to get rid of r8169_csum_workaround() completely in a subsequent step. Like in the vendor driver disable HW csum for short packets on RTL8168b. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Set GSO max size and max segment number as in the vendor driver. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jonathan Lemon authored
ipv6_find_hdr() prints a non-rate limited error message when it cannot find an ipv6 header at a specific offset. This could be used as a DoS, so just remove it. Signed-off-by: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Align setting PME with the vendor driver. PMEnable is writable on RTL8169 only, on later chip versions it's read-only. PME_SIGNAL is used on chip versions from RTL8168evl with the exception of the RTL8168f family. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Davide Caratti authored
ConnectX-3 Pro can offload transmission of VLAN packets with VXLAN inside: enable tunnel offloads in dev->vlan_features, like it's done with other NIC drivers (e.g. be2net and ixgbe). It's no more necessary to change dev->hw_enc_features when VXLAN are added or removed, since .ndo_features_check() already checks for VXLAN packet where the UDP destination port matches the configured value. Just set dev->hw_enc_features when the NIC is initialized, so that overlying VLAN can correctly inherit the tunnel offload capabilities. Changes since v1: - avoid flipping hw_enc_features, instead of calling netdev notifiers, thanks to Saeed Mahameed - squash two patches into a single one CC: Paolo Abeni <pabeni@redhat.com> CC: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Davide Caratti <dcaratti@redhat.com> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nathan Chancellor authored
When CONFIG_ACPI is unset (arm allyesconfig), status is unused. drivers/net/ethernet/apm/xgene/xgene_enet_xgmac.c:383:14: warning: unused variable 'status' [-Wunused-variable] acpi_status status; ^ drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:440:14: warning: unused variable 'status' [-Wunused-variable] acpi_status status; ^ drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:697:14: warning: unused variable 'status' [-Wunused-variable] acpi_status status; ^ Move the declaration into the CONFIG_ACPI block so that there are no compiler warnings. Fixes: 570d785b ("drivers: net: xgene: Remove acpi_has_method() calls") Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thierry Reding authored
The stmmaceth clock is specified by the slave_bus and apb_pclk clocks in the device tree bindings for snps,dwc-qos-ethernet-4.10 compatible nodes of this IP. The subdrivers for these bindings will be requesting the stmmac clock correctly at a later point, so there is no need to request it here and cause an error message to be printed to the kernel log. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Thierry Reding authored
The Tegra EQOS driver already resets the MDIO bus at probe time via the reset GPIO specified in the phy-reset-gpios device tree property. There is no need to reset the bus again later on. This avoids the need to query the device tree for the snps,reset GPIO, which is not part of the Tegra EQOS device tree bindings. This quiesces an error message from the generic bus reset code if it doesn't find the snps,reset related delays. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
The variable bucket is being initialized with a value that is never read and it is being updated later with a new value in a following for-loop. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 26 Jul, 2019 3 commits
-
-
Sergej Benilov authored
Implement ethtool's EEPROM dump command (ethtool -e|--eeprom-dump). Thx to Andrew Lunn for comments. Signed-off-by: Sergej Benilov <sergej.benilov@googlemail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
drivers/staging/octeon/ethernet-tx.c:287:23: error: implicit declaration of function 'skb_drag_size'; did you mean 'skb_frag_size'? [-Werror=implicit-function-declaration] From kernelci report: https://kernelci.org/build/id/5d3943f859b514103f688918/logs/ Fixes: 92493a2f ("Build fixes for skb_frag_size conversion") Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jisheng Zhang authored
devm_platform_ioremap_resource() wraps platform_get_resource() and devm_ioremap_resource() in a single helper, let's use that helper to simplify the code. Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 25 Jul, 2019 8 commits
-
-
David S. Miller authored
Tuong Lien says: ==================== tipc: link changeover issues This patch series is to resolve some issues found with the current link changeover mechanism, it also includes an optimization for the link synching. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tuong Lien authored
In conjunction with changing the interfaces' MTU (e.g. especially in the case of a bonding) where the TIPC links are brought up and down in a short time, a couple of issues were detected with the current link changeover mechanism: 1) When one link is up but immediately forced down again, the failover procedure will be carried out in order to failover all the messages in the link's transmq queue onto the other working link. The link and node state is also set to FAILINGOVER as part of the process. The message will be transmited in form of a FAILOVER_MSG, so its size is plus of 40 bytes (= the message header size). There is no problem if the original message size is not larger than the link's MTU - 40, and indeed this is the max size of a normal payload messages. However, in the situation above, because the link has just been up, the messages in the link's transmq are almost SYNCH_MSGs which had been generated by the link synching procedure, then their size might reach the max value already! When the FAILOVER_MSG is built on the top of such a SYNCH_MSG, its size will exceed the link's MTU. As a result, the messages are dropped silently and the failover procedure will never end up, the link will not be able to exit the FAILINGOVER state, so cannot be re-established. 2) The same scenario above can happen more easily in case the MTU of the links is set differently or when changing. In that case, as long as a large message in the failure link's transmq queue was built and fragmented with its link's MTU > the other link's one, the issue will happen (there is no need of a link synching in advance). 3) The link synching procedure also faces with the same issue but since the link synching is only started upon receipt of a SYNCH_MSG, dropping the message will not result in a state deadlock, but it is not expected as design. The 1) & 3) issues are resolved by the last commit that only a dummy SYNCH_MSG (i.e. without data) is generated at the link synching, so the size of a FAILOVER_MSG if any then will never exceed the link's MTU. For the 2) issue, the only solution is trying to fragment the messages in the failure link's transmq queue according to the working link's MTU so they can be failovered then. A new function is made to accomplish this, it will still be a TUNNEL PROTOCOL/FAILOVER MSG but if the original message size is too large, it will be fragmented & reassembled at the receiving side. Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Tuong Lien authored
This commit along with the next one are to resolve the issues with the link changeover mechanism. See that commit for details. Basically, for the link synching, from now on, we will send only one single ("dummy") SYNCH message to peer. The SYNCH message does not contain any data, just a header conveying the synch point to the peer. A new node capability flag ("TIPC_TUNNEL_ENHANCED") is introduced for backward compatible! Acked-by: Ying Xue <ying.xue@windriver.com> Acked-by: Jon Maloy <jon.maloy@ericsson.com> Suggested-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: Tuong Lien <tuong.t.lien@dektech.com.au> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ding Xiang authored
devm_ioremap_resource already contains error message, so remove the redundant dev_err message Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Two small updates Patch #1, from Amit, exposes the size of the key-value database (KVD) where different entries (e.g., routes, neighbours) are stored in the device. This allows users to understand how many entries can be offloaded and is also useful for writing scale tests. Patch #2 increases the number of IPv6 nexthop groups mlxsw can offload. The problem and solution are explained in detail in the commit message. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
Unlike IPv4, the kernel does not consolidate IPv6 nexthop groups. To avoid exhausting the device's adjacency table - where nexthops are stored - the driver does this consolidation instead. Each nexthop group is hashed by XOR-ing the interface indexes of all the member nexthop devices. However, the ifindex itself is not hashed, which can result in identical keys used for different groups and finally an -EBUSY error from rhashtable due to too long objects list. Improve the situation by hashing the ifindex itself. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Amit Cohen authored
Unlike Spectrum-1, the KVD (Key-value database) of Spectrum-2 is not partitioned, so only expose the entire KVD size. This enables users to query the total size of the KVD. Signed-off-by: Amit Cohen <amitc@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Wolfram Sang authored
Move from i2c_new_dummy() to i2c_new_dummy_device(). So, we now get an ERRPTR which we use in error handling. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 24 Jul, 2019 17 commits
-
-
Arnd Bergmann authored
The mlx4_dev_cap and mlx4_init_hca_param are really too large to be put on the kernel stack, as shown by this clang warning: drivers/net/ethernet/mellanox/mlx4/main.c:3304:12: error: stack frame size of 1088 bytes in function 'mlx4_load_one' [-Werror,-Wframe-larger-than=] With gcc, the problem is the same, but it does not warn because it does not inline this function, and therefore stays just below the warning limit, while clang is just above it. Use kzalloc for dynamic allocation instead of putting them on stack. This gets the combined stack frame down to 424 bytes. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Saeed Mahameed <saeedm@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Arnd Bergmann authored
clang warns about an overly large stack frame in one function when it decides to inline all __qed_get_vport_*() functions into __qed_get_vport_stats(): drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=] Use a noinline_for_stack annotation to prevent clang from inlining these, which keeps the maximum stack usage at around half of that in the worst case, similar to what we get with gcc. Fixes: 86622ee7 ("qed: Move statistics to L2 code") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
This patch improves and simplifies rtl_set_rx_mode a little. No functional change intended. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2019-07-24 This series contains updates to igc and e1000e client drivers only. Sasha provides a couple of cleanups to remove code that is not needed and reduce structure sizes. Updated the MAC reset flow to use the device reset flow instead of a port reset flow. Added addition device id's that will be supported. Kai-Heng Feng provides a workaround for a possible stalled packet issue in our ICH devices due to a clock recovery from the PCH being too slow. v2: removed the last patch in the series that supposedly fixed a MAC/PHY de-sync potential issue while waiting for additional information from hardware engineers. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Qian Cai authored
The linux-next commit "net: Rename skb_frag_t size to bv_len" [1] introduced a compilation error on powerpc as it forgot to deal with the renaming from "size" to "bv_len" for ixgbevf. [1] https://lore.kernel.org/netdev/20190723030831.11879-1-willy@infradead.org/T/#md052f1c7de965ccd1bdcb6f92e1990a52298eac5 In file included from ./include/linux/cache.h:5, from ./include/linux/printk.h:9, from ./include/linux/kernel.h:15, from ./include/linux/list.h:9, from ./include/linux/module.h:9, from drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:12: drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c: In function 'ixgbevf_xmit_frame_ring': drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:4138:51: error: 'skb_frag_t' {aka 'struct bio_vec'} has no member named 'size' count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size); ^ ./include/uapi/linux/kernel.h:13:40: note: in definition of macro '__KERNEL_DIV_ROUND_UP' #define __KERNEL_DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d)) ^ drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c:4138:12: note: in expansion of macro 'TXD_USE_COUNT' count += TXD_USE_COUNT(skb_shinfo(skb)->frags[f].size); Signed-off-by: Qian Cai <cai@lca.pw> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Masanari Iida authored
This patch fix some spelling typo in qos_mc_aware.sh Signed-off-by: Masanari Iida <standby24x7@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
YueHaibing authored
Now if CONFIG_ETHERNET is not set, QLGE driver building fails: drivers/staging/qlge/qlge_main.o: In function `qlge_remove': drivers/staging/qlge/qlge_main.c:4831: undefined reference to `unregister_netdev' Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 955315b0 ("qlge: Move drivers/net/ethernet/qlogic/qlge/ to drivers/staging/qlge/") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Corentin Musard authored
Replace "additonal" by "additional" in a comment. Typo found by checkpatch.pl. Signed-off-by: Corentin Musard <corentinmusard@gmail.com> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kai-Heng Feng authored
This works around a possible stalled packet issue, which may occur due to clock recovery from the PCH being too slow, when the LAN is transitioning from K1 at 1G link speed. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
Add support for more SKUs. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
Use Device Reset flow instead of Port Reset flow. This flow performs a reset of the entire controller device, resulting in a state nearly approximating the state following a power-up reset or internal PCIe reset, except for system PCI configuration. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
This patch comes to clean up the device specification structure. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
Polarity and cable length fields is not applicable for the i225 device. This patch comes to clean up PHY information structure. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Matthew Wilcox (Oracle) authored
I missed a few places. One is in some ifdeffed code which will probably never be re-enabled; the others are in drivers which can't currently be compiled on x86. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Chuhong Yuan authored
Instead of using to_pci_dev + pci_get_drvdata, use dev_get_drvdata to make code simpler. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-