- 29 Feb, 2016 40 commits
-
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 When comparing MAC addresses, use ether_addr_equal instead of memcmp to ETH_ALEN length. Found and replaced using the following sed: sed -e 's/memcmp\x28\(.*\), ETH_ALEN\x29/!ether_addr_equal\x28\1\x29/' Reported-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
Krishneil Singh <Krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 6186ddf0) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536475 This patch is meant to cleanup the exception handling for the paths where we reset the interrupts and then reconfigure them. In all of these paths we had very different levels of exception handling. I have updated the driver so that all of the paths should result in a similar state if we fail. Specifically the driver will now unload the mailbox interrupt, free the queue vectors and MSI-X, and then detach the interface. In addition for any of the PCIe related resets I have added a check with the hw_ready function to just make sure the registers are in a readable state prior to reopening the interface. Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Reviewed-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 The TLV format for little endian structures is actually 4 byte aligned copy. To this end, we need to add an additional __aligned(4) marker along with __packed to ensure that these structures are actually 4 byte aligned and packed correctly. Use of just __packed will not work as this will result in 1byte alignment which is incorrect. Add a comment explaining the reasoning behind why these structures need the special treatment. Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Cleans up checkpatch GLOBAL_INITIALIZERS error Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Similar to ixgbe and i40e, initialize XPS on driver load so that we can take advantage of this kernel feature. Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Make functions that should be static. While we're at it, fix the function header comment for fm10k_tlv_attr_nest_stop(), and update the copyright header for fm10k_pf.h, fm10k_tlv.c and fm10k_tlv.h. Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475 The function declaration does not need to be 'inline'd here. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536475 This patch addresses two issues. First is the fact that the fm10k_mbx_free_irq was assuming msix_entries was valid and that will not always be the case. As such we need to add a check for if it is NULL. Second is the fact that we weren't freeing the IRQ if the mailbox API returned an error on trying to connect. Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1536475 If the q_vector allocation fails we should free the resources associated with the MSI-X vector table. Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Rather than wrapping fm10k_dcbnl.c and fm10k_debugfs.c support with #ifdef blocks, just conditionally include the .o files in the Makefile. Also, since we're modifying it, update the copyright year on the Makefile. Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 We haven't bumped the driver version in a while despite many fixes being pulled in from the out-of-tree Sourceforge driver. Update the version to match. Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Instead of using lowercase vlan, vid, or VID, always use VLAN or VLAN ID in comments when referring to VLANs. The original driver code was consistent, but recent patches have not been as consistent with this naming scheme. Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Improve code style by removing the unnecessary else block of an if statement which immediately returns. Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Avoid the use of CamelCase for some variable names that previously slipped through review. Reported-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Use the ether_addr_copy function instead of copying byte-by-byte in a for-loop by hand. Reported-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Jacob Keller authored
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 authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Jacob Keller authored
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 authored
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 authored
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:
-
Jacob Keller authored
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 authored
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 authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
Jacob Keller authored
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:
-
Jacob Keller authored
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 authored
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 authored
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 authored
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:
-
Alexander Duyck authored
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 authored
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:
-
Jacob Keller authored
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:
-
Jacob Keller authored
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:
-
Suravee Suthikulpanit authored
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 b33af11d) Signed-off-by:
-
Loc Ho authored
The X-Gene clock driver missed the divider shift operation when set the divider value. Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> (cherry picked from commit 1382ea63) Signed-off-by:
-
