- 29 Feb, 2016 40 commits
-
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1533035 Currently the property accessors unconditionally fall back to built-in property set as a last resort. Make this strict and return an error in case the type of fwnode is unknown. This is actually a follow up to the commit 4fa7508e (device property: Return -ENXIO if there is no suitable FW interface). Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit e3f9e299) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138011.html When secondaries are napping in kvm_unsplit_nap() with hwthread_req = 1, the HMI goes ignored even though subcores are already exited the guest. Hence HMI keeps waking up secondaries from nap in a loop and secondaries always go back to nap since no vcore is assigned to them. This makes impossible for primary thread to get hold of secondary threads resulting into a soft lockup in KVM path. This patch fixes this by adding a HMI check just before the thread goes to unsplit nap. Signed-off-by:
Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138010.html When a guest is assigned to a core it converts the host Timebase (TB) into guest TB by adding guest timebase offset before entering into guest. During guest exit it restores the guest TB to host TB. This means under certain conditions (Guest migration) host TB and guest TB can differ. When we get an HMI for TB related issues the opal HMI handler would try fixing errors and restore the correct host TB value. With no guest running, we don't have any issues. But with guest running on the core we run into TB corruption issues. If we get an HMI while in the guest, the current HMI handler invokes opal hmi handler before forcing guest to exit. The guest exit path subtracts the guest TB offset from the current TB value which may have already been restored with host value by opal hmi handler. This leads to incorrect host and guest TB values. With split-core, things become more complex. With split-core, TB also gets split and each subcore gets its own TB register. When a hmi handler fixes a TB error and restores the TB value, it affects all the TB values of sibling subcores on the same core. On TB errors all the thread in the core gets HMI. With existing code, the individual threads call opal hmi handle independently which can easily throw TB out of sync if we have guest running on subcores. Hence we will need to co-ordinate with all the threads before making opal hmi handler call followed by TB resync. This patch introduces a sibling subcore state structure (shared by all threads in the core) in paca which holds information about whether sibling subcores are in Guest mode or host mode. An array in_guest[] of size MAX_SUBCORE_PER_CORE=4 is used to maintain the state of each subcore. The subcore id is used as index into in_guest[] array. Only primary thread entering/exiting the guest is responsible to set/unset its designated array element. On TB error, we get HMI interrupt on every thread on the core. Upon HMI, this patch will now force guest to vacate the core/subcore. Primary thread from each subcore will then turn off its respective bit from the above bitmap during the guest exit path just after the guest->host partition switch is complete. All other threads that have just exited the guest OR were already in host will wait until all other subcores clears their respective bit. Once all the subcores turn off their respective bit, all threads will will make call to opal hmi handler. It is not necessary that opal hmi handler would resync the TB value for every HMI interrupts. It would do so only for the HMI caused due to TB errors. For rest, it would not touch TB value. Hence to make things simpler, primary thread would call TB resync explicitly once for each core immediately after opal hmi handler instead of subtracting guest offset from TB. TB resync call will restore the TB with host value. Thus we can be sure about the TB state. One of the primary threads exiting the guest will take up the responsibility of calling TB resync. It will use one of the top bits (bit 63) from subcore state flags bitmap to make the decision. The first primary thread (among the subcores) that is able to set the bit will have to call the TB resync. Rest all other threads will wait until TB resync is complete. Once TB resync is complete all threads will then proceed. Signed-off-by:
-
Mahesh Salgaonkar authored
BugLink: http://bugs.launchpad.net/bugs/1537881 https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-January/138009.html OPAL_CALL wrapper code sticks the r1 (stack pointer) into PACAR1 purely for debugging purpose only. The power7_wakeup* functions relies on stack pointer saved in PACAR1. Any opal call made using opal wrapper (directly or in-directly) before we fall through power7_wakeup*, then it ends up replacing r1 in PACAR1(r13) leading to kernel panic. So far we don't see any issues because we have never made any opal calls using OPAL wrapper before power7_wakeup*. But the subsequent HMI patch would need to invoke C calls during cpu wakeup/idle path that in-directly makes opal call using opal wrapper. This patch facilitates the subsequent HMI patch by removing usage of PACAR1 from opal call wrapper. Signed-off-by:
-
John Johansen authored
BugLink: http://bugs.launchpad.net/bugs/1446906 This is a horrendous HACK, that is a temporary fix until typesplitting can land. Store off the path reference on connection to make up for the path being wiped out on socket shutdown. Signed-off-by:
John Johansen <john.johansen@canonical.com> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1537923Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Tri-states need 'if IS_ENABLED()', booleans should use 'ifdef'. Signed-off-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 0d722ec8) Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475 Cleanup a number of issues with function header comments, lower-case acronyms (i.e. FIFO, TLV), duplicate comments and a stubbed-out header comment for fm10k_sm_mbx_init. 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 These structures never change so declare them as const. Signed-off-by:
-
Bruce Allan authored
BugLink: http://bugs.launchpad.net/bugs/1536475Signed-off-by:
-
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:
Jacob Keller <jacob.e.keller@intel.com> Reviewed-by:
-
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:
-
