- 27 Jul, 2019 6 commits
-
-
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 23 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>
-
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>
-
David S. Miller authored
Merge tag 'linux-can-next-for-5.4-20190724' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2019-07-24 this is a pull request for net-next/master consisting of 26 patches. The first two patches are by me. One adds missing files of the CAN subsystem to the MAINTAINERS file, while the other sorts the Makefile/Kconfig of the sja1000 drivers sub directory. In the next patch Ji-Ze Hong (Peter Hong) provides a driver for the "Fintek PCIE to 2 CAN" controller, based on the the sja1000 IP core. Gustavo A. R. Silva's patch for the kvaser_usb driver introduces the use of struct_size() instead of open coding it. Henning Colliander's patch adds a driver for the "Kvaser PCIEcan" devices. Another patch by Gustavo A. R. Silva marks expected switch fall-throughs properly. Dan Murphy provides 5 patches for the m_can. After cleanups a framework is introduced so that the driver can be used from memory mapped IO as well as SPI attached devices. Finally he adds a driver for the tcan4x5x which uses this framework. A series of 5 patches by Appana Durga Kedareswara rao for the xilinx_can driver, first clean up,then add support for CANFD. Colin Ian King contributes another cleanup for the xilinx_can driver. Robert P. J. Day's patch corrects the brief history of the CAN protocol given in the Kconfig menu entry. 2 patches by Dong Aisheng for the flexcan driver provide PE clock source select support and dt-bindings description. 2 patches by Sean Nyekjaer for the flexcan driver provide add CAN wakeup-source property and dt-bindings description. Jeroen Hofstee's patch converts the ti_hecc driver to make use of the rx-offload helper fixing a number of outstanding bugs. The first patch of Oliver Hartkopp removes the now obsolete empty ioctl() handler for the CAN protocols. The second patch adds SPDX license identifiers for CAN subsystem. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Kelsey Skunberg authored
acpi_evaluate_object will already return an error if the needed method does not exist. Remove unnecessary acpi_has_method() calls and check the returned acpi_status for failure instead. Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Oliver Hartkopp authored
Add missing SPDX identifiers for the CAN network layer and correct the SPDX license for two of its include files to make sure the BSD-3-Clause applies for the entire subsystem. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Oliver Hartkopp authored
With commit c7cbdbf2 ("net: rework SIOCGSTAMP ioctl handling") the only ioctl function in can_ioctl() has been removed. As this SIOCGSTAMP ioctl command is now handled in net/socket.c we can entirely remove the CAN specific ioctl functions. Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Jeroen Hofstee authored
As already mentioned in [1] and included in [2], there is an off by one issue since the high bank is already enabled when the _next_ mailbox to be read has index 12, so the mailbox being read was 13. The message can therefore go into mailbox 31 and the driver will be repolled until the mailbox 12 eventually receives a msg. Or the message might end up in the 12th mailbox, but then it would become disabled after reading it and only be enabled again in the next "round" after mailbox 13 was read, which can cause out of order messages, since the lower priority mailboxes can accept messages in the meantime. As mentioned in [3] there is a hardware race condition when changing the CANME register while messages are being received. Even when including a busy poll on reception, like in [2] there are still overflows and out of order messages at times, but less then without the busy loop polling. Unlike what the patch suggests, the polling time is not in the microsecond range, but takes as long as a current CAN bus reception needs to finish, so typically more in the fraction of millisecond range. Since the timeout is in jiffies it won't timeout. Even with these additional fixes the driver is still not able to provide a proper FIFO which doesn't drop packages. So change the driver to use rx-offload and base order on timestamp instead of message box numbers. As a side affect, this also fixes [4] and [5]. Before this change messages with a single byte counter were dropped / received out of order at a bitrate of 250kbit/s on an am3517. With this patch that no longer occurs up to and including 1Mbit/s. [1] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post6 [2] http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=02346892777f07245de4d5af692513ebd852dcb2 [3] https://linux-can.vger.kernel.narkive.com/zgO9inVi/patch-can-ti-hecc-fix-rx-wrong-sequence-issue#post5 [4] https://patchwork.ozlabs.org/patch/895956/ [5] https://www.spinics.net/lists/netdev/msg494971.html Cc: Anant Gole <anantgole@ti.com> Cc: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Jeroen Hofstee <jhofstee@victronenergy.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-