- 29 Feb, 2016 40 commits
-
-
Benjamin Poirier authored
In msi-x mode, there is no handler for the lsc interrupt so there is no point in writing that to ics now that we always assume Other interrupts are caused by lsc. Reviewed-by:
Jasna Hodzic <jhodzic@ucdavis.edu> Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit a61cfe4f) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Benjamin Poirier authored
Removes the ICR read in the other interrupt handler, uses EIAC to autoclear the Other bit from ICR and IMS. This allows us to avoid interference with Rx and Tx interrupts in the Other interrupt handler. The information read from ICR is not needed. IMS is configured such that the only interrupt cause that can trigger the Other interrupt is Link Status Change. Signed-off-by:
-
Benjamin Poirier authored
msi-x interrupts are not shared so there's no need to check if the interrupt was really from this adapter. Signed-off-by:
-
Alexander Duyck authored
The function e1000e_up always returns 0. As such we can convert it to a void and just ignore the results. This allows us to drop some code in a couple spots as we no longer need to worry about non-zero return values. Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
-
Raanan Avargil authored
i219-LM (3) is a LOM that will be available on systems with the Lewisburg Platform Controller Hub (PCH) chipset from Intel. This patch provides the initial support for the device. Signed-off-by:
Raanan Avargil <raanan.avargil@intel.com> Tested-by:
-
Raanan Avargil authored
Due to timing changes to the ME firmware in Skylake, this timer needs to be increased to 300ms. Signed-off-by:
-
Dmitry Fleytman authored
This patch fixes possible division by zero in receive interrupt handler when working without adaptive interrupt moderation. The adaptive interrupt moderation mechanism is typically disabled on jumbo MTUs. Signed-off-by:
Dmitry Fleytman <dmitry@daynix.com> Signed-off-by:
Leonid Bloch <leonid@daynix.com> Tested-by:
-
Janusz Wolak authored
Signed-off-by:
Janusz Wolak <januszvdm@gmail.com> Acked-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by:
-
Jean Sacren authored
By using goto statement, we can achieve sharing the same exit path so that code duplication could be minimized. Signed-off-by:
Jean Sacren <sakiwit@gmail.com> Tested-by:
-
Jean Sacren authored
Due to historical reason, 'phy_data' has never been included in the kernel doc. Fix it so that the requirement could be fulfilled. Signed-off-by:
-
Jean Sacren authored
The local variable 'ret' doesn't serve much purpose so we might as well clean it up. Signed-off-by:
-
Jean Sacren authored
Use 'That' to replace 'The' so that the comment would make sense. Signed-off-by:
-
Jean Sacren authored
The checking logic needed some clean-up work, so we rewrite it by checking for break first. With that change in place, we can even move the second check for goto statement outside of the loop. As this is merely a cleanup, no functional change is involved. The questionable 'tmp != 0xFF' is intentionally left alone. Mark Rustad and Alexander Duyck contributed to this patch. CC: Mark Rustad <mark.d.rustad@intel.com> CC: Alex Duyck <aduyck@mirantis.com> Signed-off-by:
-
Janusz Wolak authored
Signed-off-by:
-
Dmitriy Vyukov authored
e1000_clean_tx_irq cleans buffers and sets tx_ring->next_to_clean, then e1000_xmit_frame reuses the cleaned buffers. But there are no memory barriers when buffers gets recycled, so the recycled buffers can be corrupted. Use smp_store_release to update tx_ring->next_to_clean and smp_load_acquire to read tx_ring->next_to_clean to properly hand off buffers from e1000_clean_tx_irq to e1000_xmit_frame. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by:
Dmitry Vyukov <dvyukov@google.com> Tested-by:
-
Joern Engel authored
Code was responsible for ~150ms scheduler latencies. Signed-off-by:
Joern Engel <joern@logfs.org> Signed-off-by:
Spencer Baugh <sbaugh@catern.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Right now ATR is not handling IPv6 extended headers, so ATR is not being performed on such packets. Fix that by skipping extended headers when they are present. This also fixes a problem where the ATR code was not checking that the inner protocol was actually TCP before setting up the signature rules. Since the protocol check is intimately involved with the extended header processing as well, this all gets fixed together. Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by:
-
Neerav Parikh authored
BugLink: http://bugs.launchpad.net/bugs/1536473 When FCoE is enabled with SR-IOV on the X550 NIC the hardware generates MDD events. This patch fixes these by setting the expected values in the Tx context descriptors for FCoE/FIP frames and adding a flush after writing the RDLEN register. Signed-off-by:
Neerav Parikh <neerav.parikh@intel.com> Tested-by:
-
Usha Ketineni authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Check whether the FCOE support is enabled for the devices to get the FDMI HBA attributes information instead of checking each device id. Also, add Model string information for X550. Signed-off-by:
Usha Ketineni <usha.k.ketineni@intel.com> Tested-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 If an outer UDP checksum is set, pass the skb up with CHECKSUM_NONE so that the stack will check the checksum. Do not increment an error counter, because we don't know that there is an actual error. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 In ixgbe_get_settings() the link status and speed of the interface are determined based on a read from the LINKS register via the call to mac.ops.check.link(). This can cause issues where external drivers may end up with unknown speed when calling ethtool_get_setings(). Instead of calling the mac.ops.check_link() we can report the speed from the adapter structure which is populated by the driver. Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 PFC is configuration is skipped for X550 devices due to a incorrect device id check, fixing that to include X550 PFC configuration. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Tested-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Use fcoe_ddp_xid from netdev as this is correctly set for different device IDs to avoid DDP skip error on X550 as "xid=0x20b out-of-range" Signed-off-by:
-
Vasu Dev authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Currently credit_refill and credit_max could be zero for a TC and that is causing Tx hang for CEE mode configuration, so to fix that have at min credit assigned to a TC and that is as what IEEE mode already does. Change-ID: If652c133093a21e530f4e9eab09097976f57fb12 Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 When I had rewritten the code for ixgbe_clear_vf_vlans() it looks like I had transitioned back and forth between using word as an offset and using word as a register offset. As a result I honestly don't see how the code was working before other than the fact that resetting the VLANs on the VF like didn't do much to clear them. Another issue found is that the mask was using a divide instead of a modulus. As a result the mask bit was incorrectly being set to either bit 0 or 1 based on the value of the VF being tested. As a result the wrong VFs were having their VLANs cleared if they were enabled. I have updated the code so that word represents the offset in the array. This way we can use the modulus and xor operations and they will make sense instead of being performed on a 4 byte aligned value. I replaced the statement "(word % 2) ^ 1" with "~word % 2" in order to reduce the line length as the line exceeded 80 characters with the register name inserted. The two should be equivalent so the change should be safe. Reported-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 The X550EM_x revision check needs to check a value, not just a bit. Use a mask and check the value. Also remove the redundant check inside the ixgbe_enter_lplu_t_x550em, because it can only be called when both the mac type and revision check pass. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 X550 allows for up to 64 RSS queues, but the driver can have max of 63 (-1 MSIX vector for link). On systems with >= 64 CPUs the driver will set the redirection table for all 64 queues which will result in packets being dropped. Signed-off-by:
-
Mark Rustad authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Clean up minor redundancy in the setting of hw_enc_features that makes it appears that X550 uniquely has more encapsulation features than other devices. The driver only supports one more feature, so make it look that way. No longer set NETIF_F_SG since that is set by the register_netdev call. Thanks to Alex Duyck for noticing this slight confusion. Reported-by:
-
Veola Nazareth authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Ethtool reports backplane type interfaces as 1000/10000baseT link modes. This has been corrected to report the media as KR, KX or KX4 based on the backplane interface present. Signed-off-by:
Veola Nazareth <veola.nazareth@intel.com> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Add missing QSFP PHY types to allow for more accurate reporting of port settings. Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 adapter->rx_itr_setting is not a mask so check it with == instead of & do not default to 12K interrupts in ixgbevf_set_itr() There should be no functional effect from these changes. Signed-off-by:
-
William Dauchy authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This is the same patch as for ixgbe but applied differently according to busy polling. See commit 5d6002b7 ("ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector") Signed-off-by:
William Dauchy <william@gandi.net> Tested-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1536473 Some X550 devices can connect at 2.5Gbps during fail-over, but only with certain link partners. Also setting the advertised speed will not work so we do not report it as supported to avoid confusion. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch guarantees that the VFs do not have access to VLANs that they were not supposed to. What this patch does is add code so that we delete the previous port VLAN after adding a new one, and if we reset the VF we clear all of the filters associated with it. Previously the code was leaving all previous VLANs mapped to the VF and they didn't get deleted unless the VF specifically requested it or if the PF itself was reset. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch makes certain that we clear the pool mappings added when we configure default MAC addresses for the interface. Without this we run the risk of leaking an address into pool 0 which really belongs to VF 0 when SR-IOV is enabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is a follow-on for enabling VLAN promiscuous and allowing the PF to add VLANs without adding a VLVF entry. What this patch does is go through and free the VLVF registers if they are not needed as the VLAN belongs only to the PF which is the default pool. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for VLAN promiscuous with SR-IOV enabled. The code prior to this patch was only adding the PF to VLANs that the VF had added. As such enabling promiscuous mode would actually not add any additional VLAN filters so visibility was limited. This lead to a number of issues as the bridge and OVS would expect us to accept all VLAN tagged packets when promiscuous mode was enabled, and instead we would filter out most if not all depending on the configuration of the PF. With this patch what we do is set all the bits in the VFTA and all of the VLVF bits associated with the pool belonging to the PF. By doing this the PF is guaranteed to receive all VLAN tagged traffic associated with the RAR filters assigned to the PF. In addition we will clean up those same bits in the event of promiscuous mode being disabled. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch is meant to reduce the complexity of the search function used for finding a VLVF entry associated with a given VLAN ID. The previous code was searching from bottom to top. I reordered it to search from top to bottom. In addition I pulled an AND statement out of the loop and instead replaced it with an OR statement outside the loop. This should help to reduce the overall size and complexity of the function. There was also some formatting I cleaned up in regards to whitespace and such. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch adds support for bypassing the VLVF entry creation when the PF is adding a new VLAN. The advantage to doing this is that we can then save the VLVF entries for the VFs which must have them in order to function, versus the PF which can fall back on the default pool entry. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536473 This patch addresses several issues within the VLVF and VLVFB configuration First was the fact that code was overly complicated with multiple conditional paths depending on if we adding or removing and which bit we were going to add or remove. Instead of messing with all that I have simplified it by using (vid / 32) and (1 - vid / 32) to identify our register and the other vlvfb register. Second was the fact that we were likely leaking a few packets into the PF in cases where we were deleting an entry and the VFTA filter for that entry as the ordering was such that we deleted the pool and then the VLAN filter instead of the other way around. I have updated that by adding a check for no bits being set and if that occurs we clear things up in the proper order. Signed-off-by:
-
