Jacob Keller [Fri, 16 Oct 2015 17:57:09 +0000 (10:57 -0700)]
fm10k: change default Tx ITR to 25usec
BugLink: http://bugs.launchpad.net/bugs/1536475
The current default ITR for Tx is overly restrictive. Using a simple
netperf TCP_STREAM test, we top out at about 10Gb/s for a single thread
when running using 1500 byte frames. By reducing the ITR value to 25usec
(up to 40K interrupts a second from 10K), we are able to achieve 36Gb/s
for a single thread TCP stream test.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit dbf4284886c59a17dc0081cee39039ac2a546078) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:08 +0000 (10:57 -0700)]
fm10k: use macro for default Tx and Rx ITR values
BugLink: http://bugs.launchpad.net/bugs/1536475 Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 436ea956bffd9974bc41ae9bd99930e29d9c807d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:07 +0000 (10:57 -0700)]
fm10k: Update adaptive ITR algorithm
BugLink: http://bugs.launchpad.net/bugs/1536475
The existing adaptive ITR algorithm is overly restrictive. It throttles
incorrectly for various traffic rates, and does not produce good
performance. The algorithm now allows for more interrupts per second,
and does some calculation to help improve for smaller packet loads. In
addition, take into account the new itr_scale from the hardware which
indicates how much to scale due to PCIe link speed.
Reported-by: Matthew Vick <matthew.vick@intel.com> Reported-by: Alex Duyck <alexander.duyck@gmail.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 242722dd3d0af32703d4ebb4af63c92a2c85b835) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:06 +0000 (10:57 -0700)]
fm10k: introduce ITR_IS_ADAPTIVE macro
BugLink: http://bugs.launchpad.net/bugs/1536475
Define a macro for identifying when the itr value is dynamic or
adaptive. The concept was taken from i40e. This helps make clear what
the check is, and reduces the line length to something more reasonable
in a few places.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 584373f5b98aed81ff5a432d91b6e16d7554a5c9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:05 +0000 (10:57 -0700)]
fm10k: Add support for ITR scaling based on PCIe link speed
BugLink: http://bugs.launchpad.net/bugs/1536475
The Intel Ethernet Switch FM10000 Host Interface interrupt throttle
timers are based on the PCIe link speed. Because of this, the value
being programmed into the ITR registers must be scaled accordingly.
For the PF, this is as simple as reading the PCIe link speed and storing
the result. However, in the case of SR-IOV, the VF's interrupt throttle
timers are based on the link speed of the PF. However, the VF is unable
to get the link speed information from its configuration space, so the
PF must inform it of what scale to use.
Rather than pass this scale via mailbox message, take advantage of
unused bits in the TDLEN register to pass the scale. It is the
responsibility of the PF to program this for the VF while setting up the
VF queues and the responsibility of the VF to get the information
accordingly. This is preferable because it allows the VF to set up the
interrupts properly during initialization and matches how the MAC
address is passed in the TDBAL/TDBAH registers.
Since we're modifying fm10k_type.h, we may as well also update the
copyright year.
Reported-by: Matthew Vick <matthew.vick@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 20076fa18571e2e274f51a2012ff5ef5c82e93a5) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:03 +0000 (10:57 -0700)]
fm10k: rename mbx_tx_oversized statistic to mbx_tx_dropped
BugLink: http://bugs.launchpad.net/bugs/1536475
Originally this statistic was renamed because the method of dropping was
called "drop_oversized_messages", but this logic has changed much, and
this counter does actually represent messages which we failed to
transmit for a number of reasons. Rename the counter back to tx_dropped
since this is when it will increment, and it is less confusing.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5680ea692407ce5113f3391c2e6b5dbe6eec84d8) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:02 +0000 (10:57 -0700)]
fm10k: add statistics for actual DWORD count of mbmem mailbox
BugLink: http://bugs.launchpad.net/bugs/1536475
A previous bug was uncovered by addition of a debug stat to indicate the
actual number of DWORDS we pulled from the mbmem. It turned out this was
not the same as the tx_dwords counter. While the previous bug fix should
have corrected this in all cases, add some debug stats that count the
number of DWORDs pushed or pulled from the mbmem. A future debugger may
take advantage of this statistic for debugging purposes. Since we're
modifying fm10k_mbx.h, update the copyright year as well.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 17d39fac0888bfd624f61f758c8cce60632a3394) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:57:00 +0000 (10:57 -0700)]
fm10k: Correct typecast in fm10k_update_xc_addr_pf
BugLink: http://bugs.launchpad.net/bugs/1536475
Since the resultant data type of the mac_update.mac_upper field is u16,
it does not make sense to typecast u8 variables to u32 first. Since
we're modifying fm10k_pf.c, also update the copyright year.
Reported-by: Matthew Vick <matthew.vick@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9d4955b45888b1b7c9f2a954cf6aa1269904bb98) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:56:59 +0000 (10:56 -0700)]
fm10k: reinitialize queuing scheme after calling init_hw
BugLink: http://bugs.launchpad.net/bugs/1536475
The init_hw function may fail, and in the case of VFs, it might change
the number of maximum queues available. Thus, for every flow which
checks init_hw, we need to ensure that we clear the queue scheme before,
and initialize it after. The fm10k_io_slot_reset path will end up
triggering a reset so fm10k_reinit needs this change. The
fm10k_io_error_detected and fm10k_io_resume also need to properly clear
and reinitialize the queue scheme.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 875328e4bce696e85edcda3c4b0ec80fd525e3a3) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:56:58 +0000 (10:56 -0700)]
fm10k: always check init_hw for errors
BugLink: http://bugs.launchpad.net/bugs/1536475
A recent change modified init_hw in some flows the function may fail on
VF devices. For example, if a VF doesn't yet own its own queues.
However, many callers of init_hw didn't bother to check the error code.
Other callers checked but only displayed diagnostic messages without
actually handling the consequences.
Fix this by (a) always returning and preventing the netdevice from going
up, and (b) printing the diagnostic in every flow for consistency. This
should resolve an issue where VF drivers would attempt to come up
before the PF has finished assigning queues.
In addition, change the dmesg output to explicitly show the actual
function that failed, instead of combining reset_hw and init_hw into a
single check, to help for future debugging.
Fixes: 1d568b0f6424 ("fm10k: do not assume VF always has 1 queue") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1343c65f70ee1b1f968a08b30e1836a4e37116cd) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:56:57 +0000 (10:56 -0700)]
fm10k: reset max_queues on init_hw_vf failure
BugLink: http://bugs.launchpad.net/bugs/1536475
VF drivers must detect how many queues are available. Previously, the
driver assumed that each VF has at minimum 1 queue. This assumption is
incorrect, since it is possible that the PF has not yet assigned the
queues to the VF by the time the VF checks. To resolve this, we added a
check first to ensure that the first queue is infact owned by the VF at
init_hw_vf time. However, the code flow did not reset hw->mac.max_queues
to 0. In some cases, such as during reinit flows, we call init_hw_vf
without clearing the previous value of hw->mac.max_queues. Due to this,
when init_hw_vf errors out, if its error code is not properly handled
the VF driver may still believe it has queues which no longer belong to
it. Fix this by clearing the hw->mac.max_queues on exit due to errors.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 0e8d5b5975401c83641efd5d4595e6cdbe9e9e2f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Fri, 16 Oct 2015 17:56:56 +0000 (10:56 -0700)]
fm10k: set netdev features in one location
BugLink: http://bugs.launchpad.net/bugs/1536475
Don't change netdev hw_features later in fm10k_probe, instead set all
values inside fm10k_alloc_netdev. To do so, we need to know the MAC type
(whether it is PF or VF) in order to determine what to do. This helps
ensure that all logic regarding features is co-located.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e0244903d4a6a27f9f1e8b46b89afa4130aa9164) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 29 Sep 2015 22:19:56 +0000 (15:19 -0700)]
fm10k: use napi_schedule_irqoff()
BugLink: http://bugs.launchpad.net/bugs/1536475
The fm10k_msix_clean_rings function runs from hard interrupt context or
with interrupts already disabled in netpoll.
It can use napi_schedule_irqoff() instead of napi_schedule()
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit de125aaecf3f06984dd32335f1e6a41c80b71011) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 22 Sep 2015 21:35:35 +0000 (14:35 -0700)]
fm10k: Fix handling of NAPI budget when multiple queues are enabled per vector
BugLink: http://bugs.launchpad.net/bugs/1536475
This patch corrects an issue in which the polling routine would increase
the budget for Rx to at least 1 per queue if multiple queues were present.
This would result in Rx packets being processed when the budget was 0 which
is meant to indicate that no Rx can be handled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9f872986479b6e0543eb5c615e5f9491bb04e5c1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Tue, 25 Aug 2015 20:49:11 +0000 (13:49 -0700)]
fm10k: Correct MTU for jumbo frames
BugLink: http://bugs.launchpad.net/bugs/1536475
Based on hardware testing, the host interface supports up to 15368 bytes
as the maximum frame size. To determine the correct MTU, we subtract 8
for the internal switch tag, 14 for the L2 header, and 4 for the
appended FCS header, resulting in 15342 bytes of payload for our maximum
MTU on jumbo frames.
Signed-off-by: Matthew Vick <matthew.vick@intel.com> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8c7ee6d2cacc7794a91875ef5fd8284b4a900d8c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jacob Keller [Tue, 25 Aug 2015 00:27:24 +0000 (17:27 -0700)]
fm10k: do not assume VF always has 1 queue
BugLink: http://bugs.launchpad.net/bugs/1536475
It is possible that the PF has not yet assigned resources to the VF.
Although rare, this could result in the VF attempting to read queues it
does not own and result in FUM or THI faults in the PF. To prevent this,
check queue 0 before we continue in init_hw_vf.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 1340181fe435ccb8ca2f996b8680bd9566860619) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
i2c: designware: Do not require clock when SSCN and FFCN are provided
The current driver uses input clock source frequency to calculate
values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
currently have a good way to provide the frequency information.
Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
to directly provide these values. So, the clock information should
no longer be required during probing.
However, since clk can be invalid, additional checks must be done where
we are making use of it.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Tested-by: Loc Ho <lho@apm.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
(cherry picked from commit b33af11de236fd6e25f3716182f008039ec68e93) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
irqchip/gic-v2m: acpi: Introducing GICv2m ACPI support
This patch introduces gicv2m_acpi_init(), which uses information
in MADT GIC MSI frames structure to initialize GICv2m driver.
It also exposes gicv2m_init() function, which simplifies callers
to a single GICv2m init function.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Duc Dang <dhdang@apm.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 0644b3daca28dcb320373ae20069c269c9386304) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
acpi: pci: Setup MSI domain for ACPI based pci devices
This patch introduces pci_msi_register_fwnode_provider() for irqchip
to register a callback, to provide a way to determine appropriate MSI
domain for a pci device.
It also introduces pci_host_bridge_acpi_msi_domain(), which returns
the MSI domain of the specified PCI host bridge with DOMAIN_BUS_PCI_MSI
bus token. Then, it is assigned to pci device.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rafael J. Wysocki <rjw@rjwysocki.net> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
(cherry picked from commit 471036b2b895789c2305428fd879006468e4a758) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
GCC6 (and Linaro's 2015.12 snapshot of GCC5) has a new default that uses
adrp/ldr or adrp/add to address literal pools. When CONFIG_ARM64_ERRATUM_843419
is enabled, modules built with this toolchain fail to load:
Longterm, this will likely be superseded by -mfix-cortex-a53-843419, which
should disable this optimization in the future.
Cc: stable at vger.kernel.org Fixes: df057cc7b4fa ("arm64: errata: add module build workaround for erratum #843419") BugLink: http://bugs.launchpad.net/bugs/1533009 Suggested-by: Christophe Lyon <christophe.lyon at linaro.org> Signed-off-by: dann frazier <dann.frazier at canonical.com> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Since the introduction of 82574 support in e1000e, the driver has worked
on the assumption that msi-x interrupt generation is automatically
disabled after each irq. As it turns out, this is not the case.
Currently, rx interrupts can fire multiple times before and during napi
processing. This can be a problem for users because frames that arrive
in a certain window (after adapter->clean_rx() but before
napi_complete_done() has cleared NAPI_STATE_SCHED) generate an interrupt
which does not lead to napi_schedule(). These frames sit in the rx queue
until another frame arrives (a tcp retransmit for example).
While the EIAC and CTRL_EXT registers are properly configured for irq
automask, the modification of IAM in e1000_configure_msix() is what
prevents automask from working as intended.
This patch removes that erroneous write and fixes interrupt rearming for
tx interrupts. It also clears IAME from CTRL_EXT. This is not strictly
necessary for operation of the driver but it is to avoid disruption from
potential programs that access the registers directly, like `ethregs -c`.
Reported-by: Frank Steiner <steiner-reg@bio.ifi.lmu.de> 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 0a8047ac68e50e4ccbadcfc6b6b070805b976885) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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 a61cfe4ffad7864a07e0c74969ca7ceb77ab2f1f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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 <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 16ecba59bc333d6282ee057fb02339f77a880beb) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
msi-x interrupts are not shared so there's no need to check if the
interrupt was really from this adapter.
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 4d432f67ff004dc387ba307d418d0eae4fa9dc13) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 27 Oct 2015 23:59:31 +0000 (16:59 -0700)]
e1000e: Switch e1000e_up to void, drop code checking for error result
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 386164d9b36b1f6f1396978110de85c7e186491d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Raanan Avargil [Tue, 20 Oct 2015 14:13:01 +0000 (17:13 +0300)]
e1000e: initial support for i219-LM (3)
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f3ed935de059b83394c3ecf2c64c93b57c8915fe) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Dmitry Fleytman [Tue, 13 Oct 2015 09:48:18 +0000 (12:48 +0300)]
e1000e: fix division by zero on jumbo MTUs
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b77ac46bbae862dcb3f51296825c940404c69b0f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Janusz Wolak [Mon, 28 Sep 2015 21:40:19 +0000 (23:40 +0200)]
e1000: Elementary checkpatch warnings and checks removed
Signed-off-by: Janusz Wolak <januszvdm@gmail.com> Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 13a87c124ec8a717b557cd8bc08693af021c8812) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Sacren [Sat, 19 Sep 2015 11:08:47 +0000 (05:08 -0600)]
e1000: get rid of duplicate exit path
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c619581a7903fadccb900d1d497d2366fdf7da9d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Sacren [Sat, 19 Sep 2015 11:08:46 +0000 (05:08 -0600)]
e1000: fix kernel-doc argument being missing
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 <sakiwit@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f03fed668a9193036db0258229af87e9ba46ed5e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Sacren [Sat, 19 Sep 2015 11:08:42 +0000 (05:08 -0600)]
e1000e: clean up the local variable
The local variable 'ret' doesn't serve much purpose so we might as well
clean it up.
Signed-off-by: Jean Sacren <sakiwit@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5a5e889c80cef7513a40143ee1e474acccdee13b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Sacren [Sat, 19 Sep 2015 11:08:41 +0000 (05:08 -0600)]
e1000: fix a typo in the comment
Use 'That' to replace 'The' so that the comment would make sense.
Signed-off-by: Jean Sacren <sakiwit@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b6fad9f9fc5d4deb1cb50173bd729de26570fbbe) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jean Sacren [Sat, 19 Sep 2015 11:08:40 +0000 (05:08 -0600)]
e1000: clean up the checking logic
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: Jean Sacren <sakiwit@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4e01f3a802b5910b25814e1d0fd05907edffed6f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Janusz Wolak [Thu, 17 Sep 2015 21:34:29 +0000 (23:34 +0200)]
e1000: Remove checkpatch coding style errors
Signed-off-by: Janusz Wolak <januszvdm@gmail.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a48954c88b5a9ec0a8323fff1d47a6affba31d61) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
e1000: fix data race between tx_ring->next_to_clean
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9eab46b7cb8d0b0dcf014bf7b25e0e72b9e4d929) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joern Engel [Thu, 23 Jul 2015 21:54:34 +0000 (14:54 -0700)]
e1000: make eeprom read/write scheduler friendly
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: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e09b89069ff9e3877bdbca8e64da05cde88bc3a2) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Wed, 9 Dec 2015 22:55:37 +0000 (14:55 -0800)]
ixgbe: Make ATR recognize IPv6 extended headers
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: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e19dcdeb3527e996a96ea49d86cccce768b1079a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8b75451be1fc05b6ee3f9d0eaea0006d60caff89) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Usha Ketineni [Tue, 8 Dec 2015 12:01:18 +0000 (04:01 -0800)]
ixgbe: Fix to get FDMI HBA attributes information with X550
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: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b262a9a772eae649159fd2480992713a2dd2b3d3) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 4 Dec 2015 19:26:43 +0000 (11:26 -0800)]
ixgbe: Correct handling of any outer UDP checksum setting
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: Mark Rustad <mark.d.rustad@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d469251bfd06d15289c9dd5dd60b8ebf65785b03) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Emil Tantilov [Thu, 3 Dec 2015 23:20:06 +0000 (15:20 -0800)]
ixgbe: do not call check_link for ethtool in ixgbe_get_settings()
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: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 0e4d422f5f7249324ac8d1b8e12772e530787a66) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasu Dev [Mon, 23 Nov 2015 18:31:25 +0000 (10:31 -0800)]
ixgbe: fix broken PFC with X550
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: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit cb78cf12d6e90f57f6e7d090867ef19b6a189dde) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasu Dev [Mon, 23 Nov 2015 18:31:01 +0000 (10:31 -0800)]
ixgbe: use correct FCoE DDP max check
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 <vasu.dev@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f10166aba2def9bc6443290231c60f7e2f70129b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Vasu Dev [Mon, 23 Nov 2015 18:30:51 +0000 (10:30 -0800)]
ixgbe: Fill at least min credits to a TC credit refills
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: Vasu Dev <vasu.dev@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3efcb86e2da69989827066c231edb30ec10de932) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Wed, 23 Dec 2015 17:00:35 +0000 (09:00 -0800)]
ixgbe: Fix bugs in ixgbe_clear_vf_vlans()
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: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ab3a3b7b0cf88021376d565c526aa27b1e105148) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 20 Nov 2015 21:12:17 +0000 (13:12 -0800)]
ixgbe: Correct X550EM_x revision check
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: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3ca2b2506ec9a3b1615930a6810d30ec9aba10a1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e9ee3238f8a480bbca58e51d02a93628d7c1f265) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Wed, 18 Nov 2015 23:37:04 +0000 (15:37 -0800)]
ixgbe: Clean up redundancy in hw_enc_features
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: Alexander Duyck <aduyck@mirantis.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit fb8ad4a592c627783dc18cc147c7f4de55cf318d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Veola Nazareth [Wed, 11 Nov 2015 23:22:59 +0000 (16:22 -0700)]
ixgbe: report correct media type for KR, KX and KX4 interfaces
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: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 695b816d1aeb09505f499ec7cc5e90657c8c11ac) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit af56b4d865bf40e031df9118b0663ebf406ff121) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Emil Tantilov [Thu, 5 Nov 2015 00:02:21 +0000 (16:02 -0800)]
ixgbevf: minor cleanups for ixgbevf_set_itr()
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: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 9ad3d6f7eb300d464bfce2c80e7b1594f5e5eff9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
William Dauchy [Fri, 30 Oct 2015 17:16:30 +0000 (18:16 +0100)]
ixgbevf: Fix handling of NAPI budget when multiple queues are enabled per vector
BugLink: http://bugs.launchpad.net/bugs/1536473
This is the same patch as for ixgbe but applied differently according to
busy polling. See commit 5d6002b7b822c74 ("ixgbe: Fix handling of NAPI
budget when multiple queues are enabled per vector")
Signed-off-by: William Dauchy <william@gandi.net> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d0f71afffa1c3d5a36a4a278f1dbbd2643176dc3) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Emil Tantilov [Sat, 7 Nov 2015 00:34:33 +0000 (16:34 -0800)]
ixgbe: do not report 2.5 Gbps as supported
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: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d3428001c58dce10af624e889667c7862320390a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:10:32 +0000 (17:10 -0800)]
ixgbe: Clean stale VLANs when changing port VLAN or resetting
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 4c7f35f679f592804736f9303051257de2c9f021) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:10:26 +0000 (17:10 -0800)]
ixgbe: Clear stale pool mappings
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 6e982aeae5779a67fc02c5f6873654c49af97e70) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:10:19 +0000 (17:10 -0800)]
ixgbe: Fix VLAN promisc in relation to SR-IOV
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e1d0a2af2b30f5f0cbce2e4dd438d4da2433b226) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 16369564915a9777217244678ee6160f8f1acac7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:10:07 +0000 (17:10 -0800)]
ixgbe: Reorder search to work from the top down instead of bottom up
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c2bc9ce91c31cc214667b9e1a150cd3000856c1c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:10:01 +0000 (17:10 -0800)]
ixgbe: Add support for adding/removing VLAN on PF bypassing the VLVF
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 <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit b6488b662b5011a3640033a266886603892dfed1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
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: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5ac736a65ac131e76edb5bbe75f7f9acef7a8a7b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:09:48 +0000 (17:09 -0800)]
ixgbe: Reduce VT code indent in set_vfta by introducing jump label
BugLink: http://bugs.launchpad.net/bugs/1536473
In order to clear the way for upcoming work I thought it best to drop the
level of indent in the ixgbe_set_vfta_generic function. Most of the code
is held in the virtualization specific section. So the easiest approach is
to just add a jump label and jump past the bulk of the code if it is not
enabled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 63d9379a598ed9fbb887b8679623f8a328ee394e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:09:42 +0000 (17:09 -0800)]
ixgbe: Simplify definitions for regidx and bit in set_vfta
BugLink: http://bugs.launchpad.net/bugs/1536473
This patch simplifies the logic for setting the VFTA register by removing
the number of conditional checks needed. Instead we just use some boolean
logic to generate vfta_delta, and if that is set then we xor the vfta by
that value and write it back.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c18fbd5f024e47897a120f42d128c04fa708692c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:09:35 +0000 (17:09 -0800)]
ixgbe: Fix SR-IOV VLAN pool configuration
BugLink: http://bugs.launchpad.net/bugs/1536473
The code for checking the PF bit in ixgbe_set_vf_vlan_msg was using the
wrong offset and as a result it was pulling the VLAN off of the PF even if
there were VFs numbered greater than 40 that still had the VLAN enabled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8e8e9a0b7df0194e95bb1d657f9edbdc6363f082) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 3 Nov 2015 01:09:29 +0000 (17:09 -0800)]
ixgbe: Return error on failure to allocate mac_table
BugLink: http://bugs.launchpad.net/bugs/1536473
Add a check to make certain mac_table was actually allocated and is not
NULL. If it is NULL return -ENOMEM and allow the probe routine to fail
rather then causing a NULL pointer dereference further down the line.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 530fd82a9fea5bba8e044bdf6fdf2ddc495e3807) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 19 Nov 2015 21:56:30 +0000 (13:56 -0800)]
ixgbevf: Handle extended IPv6 headers in Tx path
BugLink: http://bugs.launchpad.net/bugs/1536473
Check for and handle IPv6 extended headers so that Tx checksum
offload can be done. Also use skb_checksum_help for unexpected
cases. Thanks to Tom Herbert for noticing these problems. Thanks
to Alexander Duyck for seeing how to coalesce the error handling
into one location.
Reported-by: Tom Herbert <tom@herbertland.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d34a614adfb16a560ddb6759d532eb32b6651eae) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 5 Nov 2015 19:02:14 +0000 (11:02 -0800)]
ixgbe: Always turn PHY power on when requested
BugLink: http://bugs.launchpad.net/bugs/1536473
Instead of inhibiting PHY power control when manageability is
present, only inhibit turning PHY power off when manageability
is present. Consequently, PHY power will always be turned on when
requested. Without this patch, some systems with X540 or X550
devices in some conditions will never get link.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3c2f2b77a917488b56b2676b99adb5d3c07d6e68) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Wed, 18 Nov 2015 17:21:28 +0000 (09:21 -0800)]
ixgbe: Handle extended IPv6 headers in Tx path
BugLink: http://bugs.launchpad.net/bugs/1536473
Check for and handle IPv6 extended headers so that Tx checksum
offload can be done. Also use skb_checksum_help for unexpected
cases. Thanks to Tom Herbert for noticing these problems. Thanks
to Alexander Duyck for recognizing problems with the first version
of this patch and recognizing how to coalesce error conditions
into a single location.
Reported-by: Tom Herbert <tom@herbertland.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 36a92d7190e68e9387347695fe4625eb2c9e7e1c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 30 Oct 2015 22:29:34 +0000 (15:29 -0700)]
ixgbe: Save VF info and take references
BugLink: http://bugs.launchpad.net/bugs/1536473
Save VF device pointers and take references to speed accesses used
to monitor the device behavior to avoid slot resets. The saved
information avoids lock contention during the search used to access
each of the VFs.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 988d13073fe122f0b6a2b80b5f2aa1b0717f9edb) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 20:23:23 +0000 (13:23 -0700)]
ixgbe: Wait for master disable to be set
BugLink: http://bugs.launchpad.net/bugs/1536473
According to the datasheets, the driver should wait for the master
disable bit to read as being set before checking the status
register for master disable.
Reported-by: Dan Streetman <dan.streetman@canonical.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 48b44612738793252c97c548f3d0bd56543d5273) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 20:23:14 +0000 (13:23 -0700)]
ixgbe: Correct spec violations by waiting after reset
BugLink: http://bugs.launchpad.net/bugs/1536473
The ixgbe driver was violating the specification in the datasheet
by not waiting 1ms before checking for the reset bit clearing. This
is called out for devices supported by ixgbe, so implement the
required delay.
Reported-by: Dan Streetman <dan.streetman@canonical.com> Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit efff2e027758fd5cc739d500397f729591f32a94) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Tue, 27 Oct 2015 16:58:07 +0000 (09:58 -0700)]
ixgbe: Update PTP to support X550EM_x devices
BugLink: http://bugs.launchpad.net/bugs/1536473
The X550EM_x devices handle clocking differently, so update the
PTP implementation to accommodate them. This involves significant
changes to ixgbe's PTP code to accommodate the new range of
behaviors including things like non-power-of-2 clock wrapping.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a9763f3cb54c7f1c6a47962c814935654476d09f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Previously the code limited us to 16 unicast entries, however this was
shared between MACVLAN which wasn't limited and the FDB code which was. So
instead of treating the FDB code as a second class citizen I have updated
it so that it has access to just as many entries as the MACVLAN filters.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2f9be1665585a3757a00a6d1b8201d0ede937a34) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Thu, 22 Oct 2015 23:26:36 +0000 (16:26 -0700)]
ixgbe: Use __dev_uc_sync and __dev_uc_unsync for unicast addresses
BugLink: http://bugs.launchpad.net/bugs/1536473
This change replaces the ixgbe_write_uc_addr_list call in ixgbe_set_rx_mode
with a call to __dev_uc_sync instead. This works much better with the MAC
addr list code that was already in place and solves an issue in which you
couldn't remove an FDB address without having to reset the port.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 0f079d22834ac0529413bdee5b5aa52485942162) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Thu, 22 Oct 2015 23:26:30 +0000 (16:26 -0700)]
ixgbe: Refactor MAC address configuration code
BugLink: http://bugs.launchpad.net/bugs/1536473
In the process of tracking down a memory leak when adding/removing FDB
entries I had to go through the MAC address configuration code for ixgbe.
In the process of doing so I found a number of issues that impacted
readability and performance. This change updates the code in general to
clean it up so it becomes clear what each step is doing. From what I can
tell there a couple of bugs cleaned up in this code.
First is the fact that the MAC addresses were being double counted for the
PF. As a result once entries up to 63 had been used you could no longer
add additional filters.
A simple test case for this:
for i in `seq 0 96`
do
ip link add link ens8 name mv$i type macvlan
ip link set dev mv$i up
done
When things are working correctly RAL/H registers 1 - 97 will be consumed.
In the failing case it will stop at 63 and prevent any further filters from
being added.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit c9f53e63c2089d8154900ed06da0aa7be9f74201) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:20 +0000 (17:21 -0700)]
ixgbevf: Minor cleanups
BugLink: http://bugs.launchpad.net/bugs/1536473
Make some minor cleanups, such as simplifying return paths, deleting
unneeded initializations, return values more directly and so forth.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 50985b5f62cc74e9e222f0ddf890e1ba87be371a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:15 +0000 (17:21 -0700)]
ixgbevf: Use a private workqueue to avoid certain possible hangs
BugLink: http://bugs.launchpad.net/bugs/1536473
Use a private workqueue to avoid hangs that were otherwise possible
when performing stress tests, such as creating and destroying many
VFS repeatedly.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 40a13e2493c9882cb4d09054d81a5063cd1589a2) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Thu, 22 Oct 2015 00:21:10 +0000 (17:21 -0700)]
ixgbe: Use private workqueue to avoid certain possible hangs
BugLink: http://bugs.launchpad.net/bugs/1536473
Use a private workqueue to avoid hangs that were otherwise possible
when performing stress tests, such as creating and destroying many
VFS repeatedly.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 780484d853d096b4253b966e1789c4f338dd7301) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Mon, 19 Oct 2015 16:22:14 +0000 (09:22 -0700)]
ixgbe: Add support for newer thermal alarm
BugLink: http://bugs.launchpad.net/bugs/1536473
The newer copper PHY implementation used with newer X550EM_x
devices uses a different thermal alarm type than the earlier
one. Make changes to support both types.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 83a9fb20ecc4bb8b36a610ab833962fed52db64c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Fri, 16 Oct 2015 20:27:49 +0000 (13:27 -0700)]
ixgbe: Prevent KR PHY reset in ixgbe_init_phy_ops_x550em
BugLink: http://bugs.launchpad.net/bugs/1536473
This patch removes KR PHY reset from ixgbe_init_phy_ops_x550em,
since this function is meant to initialize function pointers for
the detected PHY type. Internal PHY reset was moved to
ixgbe_setup_internal_phy_t_x550em which will now detect which
mode the internal PHY operates in and set it up as required.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit f164b84529e3bf9ae43882fd3ac84bef94d104cf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Emil Tantilov [Mon, 12 Oct 2015 17:56:00 +0000 (10:56 -0700)]
ixgbevf: fix spoofed packets with random MAC
BugLink: http://bugs.launchpad.net/bugs/1536473
If ixgbevf is loaded while the corresponding PF interface is down
and the driver assigns a random MAC address, that address can be
overwritten with the value of hw->mac.perm_addr, which would be 0 at
that point.
To avoid this case we init hw->mac.perm_addr to the randomly generated
address and do not set it unless we receive ACK from ixgbe.
Reported-by: John Greene <jogreene@redhat.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 465fc643c2dcbe08e0debac80c225f6750b40d3c) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 91a76baadec1f30e8441c3d52c2559468a4da693) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d206563ad8f6fb41943366cf22f1aabc19d2b1a7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 29 Sep 2015 22:19:43 +0000 (15:19 -0700)]
ixgbe/ixgbevf: use napi_schedule_irqoff()
BugLink: http://bugs.launchpad.net/bugs/1536473
The ixgbe_intr and ixgbe/ixgbevf_msix_clean_rings functions run from hard
interrupt context or with interrupts already disabled in netpoll.
They can use napi_schedule_irqoff() instead of napi_schedule()
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit ef2662b2a820aaca4c147b91659bf57c06688ede) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The same logic applies here as well as the same results since a netperf
test will starve for memory in the time from one Tx interrupt to the next.
As a result the ixgbevf driver underperformed when compared to vhost_net.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 8a9ca1104da0de6dd8551237e7d0e50eeeea4e80) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Mark Rustad [Mon, 28 Sep 2015 21:37:47 +0000 (14:37 -0700)]
ixgbe: Add KR mode support for CS4227 chip
BugLink: http://bugs.launchpad.net/bugs/1536473
KR auto-neg mode is what we will be using going forward. The SW
interface for this mode is different that what was used for iXFI.
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d91e3a7d624590220e31ccb80a6fb5247cbfa64a) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 22 Sep 2015 21:35:41 +0000 (14:35 -0700)]
ixgbe: Fix handling of NAPI budget when multiple queues are enabled per vector
BugLink: http://bugs.launchpad.net/bugs/1536473
This patch corrects an issue in which the polling routine would increase
the budget for Rx to at least 1 per queue if multiple queues were present.
This would result in Rx packets being processed when the budget was 0 which
is meant to indicate that no Rx can be handled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 5d6002b7b822c7423e75d4651e6790bfb5642b1b) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
1) The function name is missing;
2) The format is wrong;
3) The short description is redundant.
Fix all the above for the correct execution of the kernel doc.
Signed-off-by: Jean Sacren <sakiwit@gmail.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit a897a2adb602fe3d9223aa59393be07341d3a124) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Mark Rustad <mark.d.rustad@intel.com> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit cc1f88ba16fa5cc4769cf25dca9fafeb1546be50) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Tested-by: Darin Miller <darin.j.miller@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit edab421a57fbdb7f7b83fb494a48c47bc719a7f0) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joe Schultz [Tue, 3 Nov 2015 18:37:29 +0000 (12:37 -0600)]
igb: Explicitly label self-test result indices
Previously, the ethtool self-test gstrings/data arrays were accessed via
hardcoded indices, which made the code difficult to follow. This patch
replaces the hardcoded values with enum-based labels.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit d602de05934c1d3022b153ff879e81f65df2a7b6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Joe Schultz [Tue, 3 Nov 2015 18:37:24 +0000 (12:37 -0600)]
igb: Improve cable length function for I210, etc.
Previously, the PHY-specific code to get the cable length for the
I210 internal and related PHYs was reporting the cable length of a
single pair and reporting it as the min, max, and total cable length.
Update it so that all four pairs are checked so the true min, max,
and average cable lengths are reported.
Signed-off-by: Joe Schultz <jschultz@xes-inc.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 3627f8f1d137f6487e51ff1199a54a087a2a6446) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Aaron Sierra [Tue, 3 Nov 2015 18:37:18 +0000 (12:37 -0600)]
igb: Don't add PHY address to PCDL address
There is no reason to add the PHY address into the PCDL register address.
Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 06b0dd64923b5598a52de4c889a116c49493bf97) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Aaron Sierra [Tue, 3 Nov 2015 18:37:09 +0000 (12:37 -0600)]
igb: Remove GS40G specific defines/functions
The I210 internal PHY can be accessed just as well with the access
functions shared by 82580, I350, and I354 devices. A side effect of
relying on the common functions, is that I210 cable length support
is folded back into the common case which effectively reverts the
following commit:
igb: Update get cable length function for i210/i211
Cc: Carolyn Wyborny <carolyn.wyborny@intel.com> Signed-off-by: Aaron Sierra <asierra@xes-inc.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 2a3cdead8b408351fa1e3079b220fa331480ffbc) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Jarod Wilson [Mon, 19 Oct 2015 15:52:04 +0000 (11:52 -0400)]
igb: improve handling of disconnected adapters
Clean up array_rd32 so that it uses igb_rd32 the same as rd32, per the
suggestion of Alexander Duyck, and use io_addr in more places, so that
we don't have the need to call E1000_REMOVED (which simply looks for a
null hw_addr) nearly as much.
Signed-off-by: Jarod Wilson <jarod@redhat.com> Acked-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit 7b06a6909555ffb0140733cc4420222604140b27) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log