- 07 Jan, 2020 15 commits
-
-
David S. Miller authored
Chen Zhou says: ==================== net: ch9200: code cleanup patch 1 introduce __func__ in debug message. patch 2 remove unnecessary return. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Chen Zhou authored
The return is not needed, remove it. Signed-off-by:
Chen Zhou <chenzhou10@huawei.com> Signed-off-by:
-
Chen Zhou authored
Use __func__ to print the function name instead of hard coded string. Signed-off-by:
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: driver updates These are a few little updates for the ionic network driver. v2: dropped IBM msi patch added fix for a compiler warning ==================== Signed-off-by: -
Shannon Nelson authored
Build checks have pointed out that 'hb' can theoretically be used before set, so let's initialize it and get rid of the compiler complaint. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Make sure the NIC drops packets that are larger than the specified MTU. The front end of the NIC will accept packets larger than MTU and will copy all the data it can to fill up the driver's posted buffers - if the buffers are not long enough the packet will then get dropped. With the Rx SG buffers allocagted as full pages, we are currently setting up more space than MTU size available and end up receiving some packets that are larger than MTU, up to the size of buffers posted. To be sure the NIC doesn't waste our time with oversized packets we need to lie a little in the SG descriptor about how long is the last SG element. At dealloc time, we know the allocation was a page, so the deallocation doesn't care about what length we put in the descriptor. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Shannon Nelson authored
Add a counter for packets dropped by the driver, typically for bad size or a receive error seen by the device. Signed-off-by:
-
Shannon Nelson authored
The subdevice concept is not being used in the driver, so drop the references to it. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 1GbE Intel Wired LAN Driver Updates 2020-01-06 This series contains updates to igc to add basic support for timestamping. Vinicius adds basic support for timestamping and enables ptp4l/phc2sys to work with i225 devices. Initially, adds the ability to read and adjust the PHC clock. Patches 2 & 3 enable and retrieve hardware timestamps. Patch 4 implements the ethtool ioctl that ptp4l uses to check what timestamping methods are supported. Lastly, added support to do timestamping using the "Start of Packet" signal from the PHY, which is now supported in i225 devices. While i225 does support multiple PTP domains, with multiple timestamping registers, we currently only support one PTP domain and use only one of the timestamping registers for implementation purposes. ==================== Signed-off-by: -
David S. Miller authored
Andrew Lunn says: ==================== Unique mv88e6xxx IRQ names There are a few boards which have multiple mv88e6xxx switches. With such boards, it can be hard to determine which interrupts belong to which switches. Make the interrupt names unique by including the device name in the interrupt name. For the SERDES interrupt, also include the port number. As a result of these patches ZII devel C looks like: 50: 0 gpio-vf610 27 Level mv88e6xxx-0.1:00 54: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-0.1:00-g1-atu-prob 56: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-0.1:00-g1-vtu-prob 58: 0 mv88e6xxx-g1 7 Edge mv88e6xxx-0.1:00-g2 61: 0 mv88e6xxx-g2 1 Edge !mdio-mux!mdio@1!switch@0!mdio:01 62: 0 mv88e6xxx-g2 2 Edge !mdio-mux!mdio@1!switch@0!mdio:02 63: 0 mv88e6xxx-g2 3 Edge !mdio-mux!mdio@1!switch@0!mdio:03 64: 0 mv88e6xxx-g2 4 Edge !mdio-mux!mdio@1!switch@0!mdio:04 70: 0 mv88e6xxx-g2 10 Edge mv88e6xxx-0.1:00-serdes-10 75: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-0.1:00-watchdog 76: 5 gpio-vf610 26 Level mv88e6xxx-0.2:00 80: 0 mv88e6xxx-g1 3 Edge mv88e6xxx-0.2:00-g1-atu-prob 82: 0 mv88e6xxx-g1 5 Edge mv88e6xxx-0.2:00-g1-vtu-prob 84: 4 mv88e6xxx-g1 7 Edge mv88e6xxx-0.2:00-g2 87: 2 mv88e6xxx-g2 1 Edge !mdio-mux!mdio@2!switch@0!mdio:01 88: 0 mv88e6xxx-g2 2 Edge !mdio-mux!mdio@2!switch@0!mdio:02 89: 0 mv88e6xxx-g2 3 Edge !mdio-mux!mdio@2!switch@0!mdio:03 90: 0 mv88e6xxx-g2 4 Edge !mdio-mux!mdio@2!switch@0!mdio:04 95: 3 mv88e6xxx-g2 9 Edge mv88e6xxx-0.2:00-serdes-9 96: 0 mv88e6xxx-g2 10 Edge mv88e6xxx-0.2:00-serdes-10 101: 0 mv88e6xxx-g2 15 Edge mv88e6xxx-0.2:00-watchdog Interrupt names like !mdio-mux!mdio@2!switch@0!mdio:01 are created by phylib for the integrated PHYs. The mv88e6xxx driver does not determine these names. ==================== Tested-by:
Chris Healy <cphealy@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Dynamically generate a unique interrupt name for the VTU and ATU, based on the device name. Signed-off-by:
-
Andrew Lunn authored
Dynamically generate a unique g2 interrupt name, based on the device name. Signed-off-by:
-
Andrew Lunn authored
Dynamically generate a unique watchdog interrupt name, based on the device name. Signed-off-by:
-
Andrew Lunn authored
Dynamically generate a unique SERDES interrupt name, based on the device name and the port the SERDES is for. For example: 95: 3 mv88e6xxx-g2 9 Edge mv88e6xxx-0.2:00-serdes-9 96: 0 mv88e6xxx-g2 10 Edge mv88e6xxx-0.2:00-serdes-10 The 0.2:00 indicates the switch and -9 indicates port 9. Signed-off-by:
-
Andrew Lunn authored
Dynamically generate a unique switch interrupt name, based on the device name. Signed-off-by:
-
- 06 Jan, 2020 25 commits
-
-
Vinicius Costa Gomes authored
For better accuracy, i225 is able to do timestamping using the Start of Packet signal from the PHY. Signed-off-by:
Vinicius Costa Gomes <vinicius.gomes@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Vinicius Costa Gomes authored
This command allows igc to report what types of timestamping are supported. ptp4l uses this to detect if the hardware supports timestamping. Signed-off-by:
-
Vinicius Costa Gomes authored
This adds support for timestamping packets being transmitted. Based on the code from i210. The basic differences is that i225 has 4 registers to store the transmit timestamps (i210 has one). Right now, we only support retrieving from one register, support for using the other registers will be added later. Signed-off-by:
-
Vinicius Costa Gomes authored
This adds support for timestamping received packets. It is based on the i210, as many features of i225 work the same way. The main difference from i210 is that i225 has support for choosing the timer register to use when timestamping packets. Right now, we only support using timer 0. The other difference is that i225 stores two timestamps in the receive descriptor, right now, we only retrieve one. Signed-off-by:
-
David S. Miller authored
Michal Kubecek says: ==================== ethtool: allow nesting of begin() and complete() callbacks The ethtool ioctl interface used to guarantee that ethtool_ops callbacks were always called in a block between calls to ->begin() and ->complete() (if these are defined) and that this whole block was executed with RTNL lock held: rtnl_lock(); ops->begin(); /* other ethtool_ops calls */ ops->complete(); rtnl_unlock(); This prevented any nesting or crossing of the begin-complete blocks. However, this is no longer guaranteed even for ioctl interface as at least ethtool_phys_id() releases RTNL lock while waiting for a timer. With the introduction of netlink ethtool interface, the begin-complete pairs are naturally nested e.g. when a request triggers a netlink notification. Fortunately, only minority of networking drivers implements begin() and complete() callbacks and most of those that do, fall into three groups: - wrappers for pm_runtime_get_sync() and pm_runtime_put() - wrappers for clk_prepare_enable() and clk_disable_unprepare() - begin() checks netif_running() (fails if false), no complete() First two have their own refcounting, third is safe w.r.t. nesting of the blocks. Only three in-tree networking drivers need an update to deal with nesting of begin() and complete() calls: via-velocity and epic100 perform resume and suspend on their own and wil6210 completely serializes the calls using its own mutex (which would lead to a deadlock if a request request triggered a netlink notification). The series addresses these problems. changes between v1 and v2: - fix inverted condition in epic100 ethtool_begin() (thanks to Andrew Lunn) ==================== Reviewed-by:Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Michal Kubecek authored
Unlike most networking drivers using begin() and complete() ethtool_ops callbacks to resume a device which is down and suspend it again when done, epic100 does not use standard refcounted infrastructure but sets device sleep state directly. With the introduction of netlink ethtool interface, we may have nested begin-complete blocks so that inner complete() would put the device back to sleep for the rest of the outer block. To avoid rewriting an old and not very actively developed driver, just add a nesting counter and only perform resume and suspend on the outermost level. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
-
Michal Kubecek authored
Unlike most networking drivers using begin() and complete() ethtool_ops callbacks to resume a device which is down and suspend it again when done, via-velocity does not use standard refcounted infrastructure but sets device sleep state directly. With the introduction of netlink ethtool interface, we may have nested begin-complete blocks so that inner complete() would put the device back to sleep for the rest of the outer block. To avoid rewriting an old and not very actively developed driver, just add a nesting counter and only perform resume and suspend on the outermost level. Signed-off-by:
-
Michal Kubecek authored
The wil6210 driver locks a mutex in begin() ethtool_ops callback and unlocks it in complete() so that all ethtool requests are serialized. This is not going to work correctly with netlink interface; e.g. when ioctl triggers a netlink notification, netlink code would call begin() again while the mutex taken by ioctl code is still held by the same task. Let's get rid of the begin() and complete() callbacks and move the mutex locking into the remaining ethtool_ops handlers except get_drvinfo which only copies strings that are not changing so that there is no need for serialization. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David Ahern authored
The recent MD5 tests added duplicate configuration in the default VRF. This change exposed a bug in existing tests designed to verify no connection when client and server are not in the same domain. The server should be running bound to the vrf device with the client run in the default VRF (the -2 option is meant for validating connection data). Fix the option for both tests. While technically this is a bug in previous releases, the tests are properly failing since the default VRF does not have any routing configuration so there really is no need to backport to prior releases. Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Christophe JAILLET authored
'gtp_encap_disable_sock(sk)' handles the case where sk is NULL, so there is no need to test it before calling the function. This saves a few line of code. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Disable checks in hardware pipeline Amit says: The hardware pipeline contains some checks that, by default, are configured to drop packets. Since the software data path does not drop packets due to these reasons and since we are interested in offloading the software data path to hardware, then these checks should be disabled in the hardware pipeline as well. This patch set changes mlxsw to disable four of these checks and adds corresponding selftests. The tests pass both when the software data path is exercised (using veth pair) and when the hardware data path is exercised (using mlxsw ports in loopback). ==================== Signed-off-by: -
Amit Cohen authored
Add test case to check that packets are not dropped when they need to be routed and their destination is link-local, i.e., 169.254.0.0/16. 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:
-
Amit Cohen authored
The check drops packets if they need to be routed and their destination IP is link-local, i.e., belongs to 169.254.0.0/16 address range. Disable the check since the kernel forwards such packets and does not drop them. Signed-off-by:
-
Amit Cohen authored
Add test case to check that packets are not dropped when they need to be routed and their source IP equals to their destination IP. Signed-off-by:
-
Amit Cohen authored
The check drops packets if they need to be routed and their source IP equals to their destination IP. Disable the check since the kernel forwards such packets and does not drop them. Signed-off-by:
-
Amit Cohen authored
Add test case to check that packets are not dropped when they need to be routed and their multicast MAC mismatched to their multicast destination IP. i.e., destination IP is multicast and * for IPV4: DMAC != {01-00-5E-0 (25 bits), DIP[22:0]} * for IPV6: DMAC != {33-33-0 (16 bits), DIP[31:0]} Signed-off-by: -
Amit Cohen authored
The check drops packets if they need to be routed and their multicast MAC mismatched to their multicast destination IP. For IPV4: DMAC is mismatched if it is different from {01-00-5E-0 (25 bits), DIP[22:0]} For IPV6: DMAC is mismatched if it is different from {33-33-0 (16 bits), DIP[31:0]} Disable the check since the kernel forwards such packets and does not drop them. Signed-off-by: -
Amit Cohen authored
Add test case to check that packets are not dropped when they need to be routed and their source IP in class E, (i.e., 240.0.0.0 – 255.255.255.254). Signed-off-by:
-
Amit Cohen authored
The check drops packets if they need to be routed and their source IP is from class E, i.e., belongs to 240.0.0.0/4 address range, but different from 255.255.255.255. Disable the check since the kernel forwards such packets and does not drop them. Signed-off-by:
-
Vinicius Costa Gomes authored
This allows the creation of the /dev/ptpX device for i225, and reading and writing the time. Signed-off-by:
-
David S. Miller authored
Huazhong Tan says: ==================== net: hns3: misc updates for -net-next This series includes some misc updates for the HNS3 ethernet driver. [patch 1] adds trace events support. [patch 2] re-organizes TQP's vector handling. [patch 3] renames the name of TQP vector. [patch 4] rewrites a log in the hclge_map_ring_to_vector(). [patch 5] modifies the name of misc IRQ vector. [patch 6] handles the unexpected speed 0 return from HW. [patch 7] replaces an unsuitable variable type. [patch 8] modifies an unsuitable reset level for HW error. ==================== Signed-off-by: -
Huazhong Tan authored
According to hardware user manual, when hardware reports error 'roc_pkt_without_key_port', the driver should assert function reset to do the recovery. So this patch uses HNAE3_FUNC_RESET to replace HNAE3_GLOBAL_RESET. Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
-
Huazhong Tan authored
In hclge_inform_reset_assert_to_vf(), variable reset_type(enum type) will be copied into msg_data whose size is 2 bytes. Currently, hip08 is a little-endian machine, so the lower two bytes of reset_type will be copied to msg_data. But when running on a big-endian machine, msg_data will have a wrong value(the higher two bytes of reset_type). So this patch modifies the type of reset_type to u16, and adds a build check in case enum hnae3_reset_type has value larger than U16_MAX. Signed-off-by:
-
Guojia Liao authored
In some case, the MAC speed get from hardware maybe 0, it should not be set to mac->speed. Signed-off-by:
Guojia Liao <liaoguojia@huawei.com> Signed-off-by:
-
Yonglong Liu authored
The misc IRQ of all the devices have the same name, so it's hard to find the right misc IRQ of the device. This patch modifies the misc IRQ names as "hclge/hclgevf"-misc- "pci name". And now the IRQ name is not related to net device name anymore, so change the HNAE3_INT_NAME_LEN to 32 bytes, and that is enough. Signed-off-by:
Yonglong Liu <liuyonglong@huawei.com> Signed-off-by:
-
