- 31 Oct, 2019 10 commits
-
-
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-10-29 This series contains updates to e1000e, igb, ixgbe and i40e drivers. Sasha adds support for Intel client platforms Comet Lake and Tiger Lake to the e1000e driver. Also adds a fix for a compiler warning that was recently introduced, when CONFIG_PM_SLEEP is not defined, so wrap the code that requires this kernel configuration to be defined. Alex fixes a potential race condition between network configuration and power management for e1000e, which is similar to a past issue in the igb driver. Also provided a bit of code cleanup since the driver no longer checks for __E1000_DOWN. Josh Hunt adds UDP segmentation offload support for igb, ixgbe and i40e. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
zhong jiang authored
It is more clear to use DEFINE_DEBUGFS_ATTRIBUTE to define debugfs file operation rather than DEFINE_SIMPLE_ATTRIBUTE. It is detected with the help of coccinelle. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
This patch adds glue logic to make pause settings per port configurable vie ethtool. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Guillaume Nault authored
This parameter has never been used. Signed-off-by: Guillaume Nault <gnault@redhat.com> Reviewed-by: Simon Horman <simon.horman@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Add downshift support for 88E1145, it uses the same downshift configuration registers as 88E1111. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Matteo Croce says: ==================== ICMP flow improvements This series improves the flow inspector handling of ICMP packets: The first two patches just add some comments in the code which would have saved me a few minutes of time, and refactor a piece of code. The third one adds to the flow inspector the capability to extract the Identifier field, if present, so echo requests and replies are classified as part of the same flow. The fourth patch uses the function introduced earlier to the bonding driver, so echo replies can be balanced across bonding slaves. v1 -> v2: - remove unused struct members - add an helper to check for the Id field - use a local flow_dissector_key in the bonding to avoid changing behaviour of the flow dissector ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
The bonding uses the L4 ports to balance flows between slaves. As the ICMP protocol has no ports, those packets are sent all to the same device: # tcpdump -qltnni veth0 ip |sed 's/^/0: /' & # tcpdump -qltnni veth1 ip |sed 's/^/1: /' & # ping -qc1 192.168.0.2 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 315, seq 1, length 64 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 315, seq 1, length 64 # ping -qc1 192.168.0.2 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 316, seq 1, length 64 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 316, seq 1, length 64 # ping -qc1 192.168.0.2 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 317, seq 1, length 64 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 317, seq 1, length 64 But some ICMP packets have an Identifier field which is used to match packets within sessions, let's use this value in the hash function to balance these packets between bond slaves: # ping -qc1 192.168.0.2 0: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 303, seq 1, length 64 0: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 303, seq 1, length 64 # ping -qc1 192.168.0.2 1: IP 192.168.0.1 > 192.168.0.2: ICMP echo request, id 304, seq 1, length 64 1: IP 192.168.0.2 > 192.168.0.1: ICMP echo reply, id 304, seq 1, length 64 Aso, let's use a flow_dissector_key which defines FLOW_DISSECTOR_KEY_ICMP, so we can balance pings encapsulated in a tunnel when using mode encap3+4: # ping -q 192.168.1.2 -c1 0: IP 192.168.0.1 > 192.168.0.2: GREv0, length 102: IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 585, seq 1, length 64 0: IP 192.168.0.2 > 192.168.0.1: GREv0, length 102: IP 192.168.1.2 > 192.168.1.1: ICMP echo reply, id 585, seq 1, length 64 # ping -q 192.168.1.2 -c1 1: IP 192.168.0.1 > 192.168.0.2: GREv0, length 102: IP 192.168.1.1 > 192.168.1.2: ICMP echo request, id 586, seq 1, length 64 1: IP 192.168.0.2 > 192.168.0.1: GREv0, length 102: IP 192.168.1.2 > 192.168.1.1: ICMP echo reply, id 586, seq 1, length 64 Signed-off-by: Matteo Croce <mcroce@redhat.com> Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
The ICMP flow dissector currently parses only the Type and Code fields. Some ICMP packets (echo, timestamp) have a 16 bit Identifier field which is used to correlate packets. Add such field in flow_dissector_key_icmp and replace skb_flow_get_be16() with a more complex function which populate this field. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
FLOW_DISSECTOR_KEY_ICMP is checked for every packet, not only ICMP ones. Even if the test overhead is probably negligible, move the ICMP dissector code under the big 'switch(ip_proto)' so it gets called only for ICMP packets. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Matteo Croce authored
Documents two piece of code which can't be understood at a glance. Signed-off-by: Matteo Croce <mcroce@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 30 Oct, 2019 30 commits
-
-
Roman Mashak authored
Two pedit tests were failing due to incorrect operation value in matchPattern, should be 'add' not 'val', so fix it. Signed-off-by: Roman Mashak <mrv@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jon Maloy authored
We introduce a feature that works like a combination of TCP_NAGLE and TCP_CORK, but without some of the weaknesses of those. In particular, we will not observe long delivery delays because of delayed acks, since the algorithm itself decides if and when acks are to be sent from the receiving peer. - The nagle property as such is determined by manipulating a new 'maxnagle' field in struct tipc_sock. If certain conditions are met, 'maxnagle' will define max size of the messages which can be bundled. If it is set to zero no messages are ever bundled, implying that the nagle property is disabled. - A socket with the nagle property enabled enters nagle mode when more than 4 messages have been sent out without receiving any data message from the peer. - A socket leaves nagle mode whenever it receives a data message from the peer. In nagle mode, messages smaller than 'maxnagle' are accumulated in the socket write queue. The last buffer in the queue is marked with a new 'ack_required' bit, which forces the receiving peer to send a CONN_ACK message back to the sender upon reception. The accumulated contents of the write queue is transmitted when one of the following events or conditions occur. - A CONN_ACK message is received from the peer. - A data message is received from the peer. - A SOCK_WAKEUP pseudo message is received from the link level. - The write queue contains more than 64 1k blocks of data. - The connection is being shut down. - There is no CONN_ACK message to expect. I.e., there is currently no outstanding message where the 'ack_required' bit was set. As a consequence, the first message added after we enter nagle mode is always sent directly with this bit set. This new feature gives a 50-100% improvement of throughput for small (i.e., less than MTU size) messages, while it might add up to one RTT to latency time when the socket is in nagle mode. Acked-by: Ying Xue <ying.xue@windreiver.com> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Update firmware version This patch set updates the firmware version for Spectrum-1 and enforces a firmware version for Spectrum-2. The version adds support for querying port module type. It will be used by a followup patch set from Jiri to make port split code more generic. Patch #1 increases the size of an existing register in order to be compatible with the new firmware version. In the future the firmware will assign default values to fields not specified by the driver. Patch #2 temporarily increases the PCI reset timeout for SN3800 systems. Note that in normal cases the driver will need to wait no longer than 5 seconds for the device to become ready following reset command. Patch #3 bumps the firmware version for Spectrum-1. Patch #4 enforces a minimum firmware version for Spectrum-2. v2: * Added patch #2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In a similar fashion to Spectrum-1, enforce a specific firmware version for Spectrum-2 so that the driver and firmware are always in sync with regards to new features. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
The version adds support for querying port module type. It will be used by a followup patch set from Jiri to make port split code more generic. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
SN3800 Spectrum-2 based systems have gearboxes that need to be initialized by the firmware during its initialization flow. In certain cases, the firmware might need to flash these gearboxes, which is currently a time-consuming process. In newer firmware versions, the firmware will not signal to the driver that it is ready until the gearboxes are flashed. Increase the PCI reset timeout for these situations. In normal cases, the driver will need to wait no longer than 5 seconds. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Ido Schimmel authored
In new firmware versions this register is extended with a sampling rate for Spectrum-2 and future ASICs. Increase the size of the register to ensure the field is initialized to 0 which means every packet is mirrored. Signed-off-by: Ido Schimmel <idosch@mellanox.com> Reviewed-by: Petr Machata <petrm@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Sasha Neftin authored
When CONFIG_PM_SLEEP is not defined compiler complain as follow: CC [M] drivers/net/ethernet/intel/e1000e/netdev.o drivers/net/ethernet/intel/e1000e/netdev.c:6302:12: warning: ‘e1000e_s0ix_entry_flow’ defined but not used [-Wunused-function] static void e1000e_s0ix_entry_flow(struct e1000_adapter *adapter) drivers/net/ethernet/intel/e1000e/netdev.c:6411:12: warning: ‘e1000e_s0ix_exit_flow’ defined but not used [-Wunused-function] static void e1000e_s0ix_exit_flow(struct e1000_adapter *adapter) LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o Add wrap to fix these warnings. Reported-by: kbuild test robot <lpk@intel.com> Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Sasha Neftin authored
Add devices ID's for the next LOM generations that will be available on the next Intel Client platform (Tiger Lake) This patch provides the initial support for these devices 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>
-
Josh Hunt authored
Based on a series from Alexander Duyck this change adds UDP segmentation offload support to the i40e driver. CC: Alexander Duyck <alexander.h.duyck@intel.com> CC: Willem de Bruijn <willemb@google.com> Signed-off-by: Josh Hunt <johunt@akamai.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Josh Hunt authored
Repost from a series by Alexander Duyck to add UDP segmentation offload support to the igb driver: https://lore.kernel.org/netdev/20180504003916.4769.66271.stgit@localhost.localdomain/ CC: Alexander Duyck <alexander.h.duyck@intel.com> CC: Willem de Bruijn <willemb@google.com> Suggested-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Josh Hunt <johunt@akamai.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Josh Hunt authored
Based on a series from Alexander Duyck this change adds UDP segmentation offload support to the igb driver. CC: Alexander Duyck <alexander.h.duyck@intel.com> CC: Willem de Bruijn <willemb@google.com> Signed-off-by: Josh Hunt <johunt@akamai.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
David S. Miller authored
Lars Poeschel says: ==================== nfc: pn533: add uart phy driver The purpose of this patch series is to add a uart phy driver to the pn533 nfc driver. It first changes the dt strings and docs. The dt compatible strings need to change, because I would add "pn532-uart" to the already existing "pn533-i2c" one. These two are now unified into just "pn532". Then the neccessary changes to the pn533 core driver are made. Then the uart phy is added. As the pn532 chip supports a autopoll, I wanted to use this instead of the software poll loop in the pn533 core driver. It is added and activated by the last to patches. The way to add the autopoll later in seperate patches is chosen, to show, that the uart phy driver can also work with the software poll loop, if someone needs that for some reason. In v11 of this patchseries I address a byte ordering issue reported by kbuild test robot in patch 5/7. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
This switches the pn532 UART phy driver from manually polling to the new autopoll mechanism. Cc: Johan Hovold <johan@kernel.org> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
pn532 devices support an autopoll command, that lets the chip automatically poll for selected nfc technologies instead of manually looping through every single nfc technology the user is interested in. This is faster and less cpu and bus intensive than manually polling. This adds this autopoll capability to the pn533 driver. Cc: Johan Hovold <johan@kernel.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
This adds the UART phy interface for the pn533 driver. The pn533 driver can be used through UART interface this way. It is implemented as a serdev device. Cc: Johan Hovold <johan@kernel.org> Cc: Claudiu Beznea <Claudiu.Beznea@microchip.com> Cc: David Miller <davem@davemloft.net> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
There is a problem in the initialisation and setup of the pn533: It registers with nfc too early. It could happen, that it finished registering with nfc and someone starts using it. But setup of the pn533 is not yet finished. Bad or at least unintended things could happen. So I split out nfc registering (and unregistering) to seperate functions that have to be called late in probe then. i2c requires a bit more love: i2c requests an irq in it's probe function. 'Commit 32ecc75d ("NFC: pn533: change order operations in dev registation")' shows, this can not happen too early. An irq can be served before structs are fully initialized. The way chosen to prevent this is to request the irq after nfc_alloc_device initialized the structs, but before nfc_register_device. So there is now this pn532_i2c_nfc_alloc function. Cc: Johan Hovold <johan@kernel.org> Cc: Claudiu Beznea <Claudiu.Beznea@microchip.com> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
This adds hooks for dev_up and dev_down to the phy_ops. They are optional. The idea is to inform the phy driver when the nfc chip is really going to be used. When it is not used, the phy driver can suspend it's interface to the nfc chip to save some power. The nfc chip is considered not in use before dev_up and after dev_down. Cc: Johan Hovold <johan@kernel.org> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
This adds documentation about the uart phy to the pn532 binding doc. As the filename "pn533-i2c.txt" is not appropriate any more, rename it to the more general "pn532.txt". This also documents the deprecation of the compatible strings ending with "...-i2c". Cc: Johan Hovold <johan@kernel.org> Cc: Simon Horman <horms@verge.net.au> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Lars Poeschel authored
It is favourable to have one unified compatible string for devices that have multiple interfaces. So this adds simply "pn532" as the devicetree binding compatible string and makes a note that the old ones are deprecated. Cc: Johan Hovold <johan@kernel.org> Cc: Simon Horman <horms@verge.net.au> Signed-off-by: Lars Poeschel <poeschel@lemonage.de> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Duyck authored
Since we no longer check for __E1000_DOWN in e1000e_close we can drop the spot where we were restoring the bit. This saves us a bit of unnecessary complexity. Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
-
Alexander Duyck authored
This patch is meant to address possible race conditions that can exist between network configuration and power management. A similar issue was fixed for igb in commit 9474933c ("igb: close/suspend race in netif_device_detach"). In addition it consolidates the code so that the PCI error handling code will essentially perform the power management freeze on the device prior to attempting a reset, and will thaw the device afterwards if that is what it is planning to do. Otherwise when we call close on the interface it should see it is detached and not attempt to call the logic to down the interface and free the IRQs again. From what I can tell the check that was adding the check for __E1000_DOWN in e1000e_close was added when runtime power management was added. However it should not be relevant for us as we perform a call to pm_runtime_get_sync before we call e1000_down/free_irq so it should always be back up before we call into this anyway. Reported-by: Morumuri Srivalli <smorumu1@in.ibm.com> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com> Tested-by: David Dai <zdai@linux.vnet.ibm.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
-
Sasha Neftin authored
Add devices ID's for the next LOM generations that will be available on the next Intel Client platform (Comet Lake) This patch provides the initial support for these devices 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>
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: convert fdbs to use bitops We'd like to have a well-defined behaviour when changing fdb flags. The problem is that we've added new fields which are changed from all contexts without any locking. We are aware of the bit test/change races and these are fine (we can remove them later), but it is considered undefined behaviour to change bitfields from multiple threads and also on some architectures that can result in unexpected results, specifically when all fields between the changed ones are also bitfields. The conversion to bitops shows the intent clearly and makes them use functions with well-defined behaviour in such cases. There is no overhead for the fast-path, the bit changing functions are used only in special cases when learning and in the slow path. In addition this conversion allows us to simplify fdb flag handling and avoid bugs for future bits (e.g. a forgetting to clear the new bit when allocating a new fdb). All bridge selftests passed, also tried all of the converted bits manually in a VM. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
No need to have separate arguments for each flag, just set the flags to whatever was passed to fdb_create() before the fdb is published. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Convert the offloaded field to a flag and use bitops. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Convert the added_by_external_learn field to a flag and use bitops. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Straight-forward convert of the added_by_user field to bitops. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Straight-forward convert of the is_sticky field to bitops. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Nikolay Aleksandrov authored
Convert the is_static to bitops, make use of the combined test_and_set/clear_bit to simplify expressions in fdb_add_entry. Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-