Bump PF version to 1.2.37 and VF version to 1.2.25

Change-ID: I0287a750408250dc055c03e1f744fd5f0caefd68
Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Fix a bug introduced in the force writeback code, where the interrupt
rate was set to 0 (maximum) by accident.

The driver must correctly set the NOITR fields to avoid ITR update
as a side effect of triggering the software interrupt.

Change-ID: I290851ae04ef3811c43aab5ee33242029f26c1a3
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NAnjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

If a reset occurs when the netdev is closed, the reset task will hang in
napi_disable, causing deadlocks and general grumpiness.

Check to make sure the device is actually running before stopping
everything. This allows the reset task to complete and have a real good
time.

Change-ID: Iaaea84acbcb9b3810c216b14c3326e4287b75b58
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

To test a checkpatch spelling patch, I ran codespell against
drivers/net/ethernet/.

$ git ls-files drivers/net/ethernet/ | \
  while read file ; do \
    codespell -w $file; \
  done

I removed a false positive in e1000_hw.h
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Bump i40e to 1.2.12 and i40evf to 1.2.6.

Change-ID: I641871da3a9abd396b28eda5744a4d68493c1400
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.11 and i40evf to 1.2.5

Change-ID: Ie13375941606b0a027e5b5dbc235f5f5f03b75c8
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.10 and i40evf to 1.2.4

Change-ID: I48aa64df05fcc8356e7026f3a9e69ecf78d0c785
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.9 and i40evf 1.2.3

Also update the copyright year.

Change-ID: I345d777e94abd0acffe6a28793f675d251a86299
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch adds the netdev name to the VF misc vector name.  Without
this patch, all the interrupts show the same info, so it difficult to
distinguish them.

Change-ID: I247828697e1373ecfb5f8dc1bc9618e98a7f4942
Signed-off-by: NCarolyn Wyborny <carolyn.wyborny@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Under rare circumstances, after a reset, set_rx_mode might get called
while the watchdog is running, which will cause a deadlock on the
critical section lock. To correct this, add a counter and give up trying
to get the lock after fifty tries. Log a message if this happens but
don't take any other action. Because this happens after a reset, all of
the Rx filters are still in place and the device won't lose
connectivity.

We can also get stuck during shutdown, if the PF has stopped communicating
with us, or if a reset is occurring. If we can't get the lock after a reasonable
amount of time, just error out. Something else bad is happening anyway, so
adding this filter is the least of our concern right now.

Change-ID: I159731e2a82a06b389ee31b34ce336548e05baa0
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

A recent change to the shutdown flow messed up the reset flow. Since
i40evf_down now holds the critical section lock, we cannot call it from
the reset handler, which also holds the lock. To do so causes a deadlock
accompanied by wailing and gnashing of teeth. This is easily triggered
by running an ethtool self-test on the PF device.

Instead, we move the relevant portions of i40evf_down into the reset
handler and bend them to our will. Additionally, we can optimize the
reinit path by not deleting the MAC and VLAN filters and then adding
them back again. Instead, we just set the 'add' flag and let the
watchdog resynchronize the filter list with the PF driver. We also
reword a few messages to make them more consistent with the rest of the
driver.

Change-ID: I03dd92ae736f7719fca3564b12a2cf9b98c6cb18
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When closing the interface, disable NAPI polling before any other
activities. This fixes an occasional panic during close caused by the
driver trying to delete and clean rings at the same time.

Change-ID: Ib4d427b13d310258ea85b248d535da70ecf0c1e9
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.8 and i40evf to 1.2.2

Change-ID: I64f47c3367ea8ff2a53068e895d7a1f60726c871
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Split the receive hot path code into two, one for packet split and one
for single buffer. This improves receive performance since we only need
to check if the ring is in packet split mode once per NAPI poll time,
not several times per packet. The single buffer code is further improved
by the removal of a bunch of code and several variables that are not
needed. On a receive-oriented test this can improve single-threaded
throughput.

Also refactor the packet split receive path to use a fixed buffer for
headers, like ixgbe does. This vastly reduces the number of DMA mappings
and unmappings we need to do, allowing for much better performance in
the presence of an IOMMU.

Lastly, correct packet split descriptor types now that we are actually
using them.

Change-ID: I3a194a93af3d2c31e77ff17644ac7376da6f3e4b
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Stop the watchdog during shutdown. Failing to do this causes a log full
of admin queue errors and the occasional hang when the system is shut
down.

Change-ID: Ib2fd11213cca2fa589eb68577e86b1000c23c250
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Occasionally on shutdown, the FW will hand us a bunch of messages filled
with zeros, which can cause us to spin trying to handle them. Just
ignore these and get on with shutting down.

Change-ID: I347e9648f7153ad5a7b7e0847b87f7aad5f3e0da
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When the module is being unloaded, don't wait for the PF to politely
handle all of our admin queue requests, as that might take forever with
a lot of VFs enabled. Instead, just stop everything and request a VF
reset.

When the original shutdown code was written, VF resets were unreliable,
so we avoided them. But with production hardware and firmware, and the
1.x PF driver, this is no longer the case.

This fixes a potential multi-minute delay on driver unload, VF disable,
or system shutdown.

Change-ID: Ib43d6d860ef6b9b8f26e8dce0615a0302608c7d9
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.6 and i40evf to 1.2.0 version.

Change-ID: Ice127eee3a5a5d1b8765d83cff8c30f9f3b1bc32
Signed-off-by: NSravanthi Tangeda <sravanthi.tangeda@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e to 1.2.5 and i40evf to 1.0.7.

Change-ID: I622556829056e3ed42d3b9d285fc5ffb693b21cc
Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

On some versions of the firmware, the VF admin send queue may become
stalled. In this case, the easiest solution is to just place another
descriptor on the queue; the firmware will then process both requests.

The early init code already accounts for this, but the runtime code does
not. In the watchdog task, check for the stall condition, and if it's
found, send our API version to the PF. When the PF replies, just ignore
the reply.

Change-ID: I380d78185a4f284d649c44d263e648afc9b4d50c
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Don't enable vector 0 in the ISR, just schedule the adminq task and let
it enable the vector. This prevents the task from being called
reentrantly. Make sure that the vector is enabled on all exit paths of
the adminq task, including error exits.

Change-ID: I53f3d14f91ed7a9e90291ea41c681122a5eca5b5
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

There is always a possibility that MSI-X interrupts can get lost. To
keep this problem from stalling the driver, we fire all of our MSI-X
vectors during the watchdog routine. However, we should not fire the
traffic vectors when the interface is closed. In this case, just fire
vector 0, which is used for admin queue events.

As a result, we do not enable the interrupt cause for vector 0. This
can cause the admin queue handler to be called reentrantly, which
causes a scary "critical section violation" message to be logged,
even though no real damage is done.

Change-ID: Ic43a5184708ab2cb9a23fca7dedd808a46717795
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

If we're using VLANs and communications with the PF fail during
shutdown, we will leak memory because not all of the VLAN filters will
be removed. To eliminate this possibility, go through the list again
right before the module is removed and delete any leftover entries.

Change-ID: Id3b5315c47ca0a61ae123a96ff345d010bc41aed
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

If the VF driver is running in the host, the shutdown code is completely
broken. We cannot wait in our down routine for the PF to respond to our
requests, as its admin queue task will never run while we hold the lock.

Instead, we schedule operations, then let the watchdog take care of
shutting things down. If the driver is being removed, then wait in the
remove routine until the watchdog is done before continuing.

Change-ID: I93a58d17389e8d6b58f21e430b56ed7b4590b2c5
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

These messages may be triggered during normal init of the driver if the
PF or FW take a long time to respond. There's nothing really wrong, so
don't freak people out logging messages.

If the communication channel really is dead, then we'll retry a few
times and give up. This will log a different more scary message that
should cause consternation. This allows the user to more easily detect a
genuine failure.

Change-ID: I6e2b758d4234a3a09c1015c82c8f2442a697cbdb
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

These functions are redundant and duplicate functionality found in
i40evf_free_all_[tx|rx]_resources.

Change-ID: Ia199908926d7a1a4b8247f75f89b5da24c9b149c
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Tested-by: NJim Young <james.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump version.

Change-ID: I4264e81dcfb57ec46a3ede54b0a6cb25b497d3cb
Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When multiple VFs attempt to initialize simultaneously, the firmware may
delay or drop messages. Make the init code more adept at handling these
situations by a) reinitializing the admin queue if the firmware fails to
process a request, and b) resending a request if the PF doesn't answer.

Once the request has been sent again, the PF might end up getting both
requests and send the configuration information to the driver twice.
This will cause the VF to complain about receiving an unexpected message
from the PF. Since this is not fatal, reduce the warning level of the
log messages that are generated in response to this event.

Change-ID: I9370a1a2fde2ad3934fa25ccfd0545edfbbb4805
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Since the if part of this statement contains a break, there's no reason
for the else. Clean up the code and make it more obvious that the delay
happens each time through the loop.

Change-ID: I9292eaf7dd687688bdc401b8bd8d1d14f6944460
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Most of the null-checking in this driver is of the style if (!foo),
except these few. Make these checks consistent with the rest of the
code.

Change-ID: I991924f34072fa607a1b626a8b3f1fa5195d43e9
Reported-by: NJoe Perches <joe@perches.com>
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

This patch is the result of running checkpatch on the i40evf driver with
the --strict option. The vast majority of changes are adding/removing
blank lines, aligning function parameters, and correcting over-long
lines.

The only possible functional change is changing the flags member of the
adapter structure to be non-volatile. However, according to the kernel
documentation, this is not necessary and the volatile should be removed.

Change-ID: Ie8c6414800924f529bef831e8845292b970fe2ed
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Overloading the msg_size field in the arq_event_info struct is just a
bad idea. It leads to repeated bugs when the structure is used in a
loop, since the input value (buffer size) is overwritten by the output
value (actual message length).

Fix this by splitting the field into two and renaming to indicate the
actual function of each field.

Since the arq_event struct has now changed, we need to change the drivers
to support this. Note that we no longer need to initialize the buffer size
each time we go through a loop as this value is no longer destroyed by
arq processing.

In the process, we also fix a bug in i40evf_verify_api_ver where the
buffer size was not correctly reinitialized each time through the loop.

Change-ID: Ic7f9633cdd6f871f93e698dfb095e29c696f5581
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Acked-by: NShannon Nelson <shannon.nelson@intel.com>
Acked-by: NAshish Shah <ashish.n.shah@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: NEric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It's kind of silly to configure and attempt to use a bunch of queue
pairs when you're running on a single (virtual) CPU. Instead of
unconditionally configuring all of the queues that the PF gives us,
clamp the number of queue pairs to the number of CPUs.

Change-ID: I321714c9e15072ee76de8f95ab9a81f86ed347d1
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NPatrick Lu <patrick.lu@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

When we receive an admin queue message, the msg_size field in the event
struct gets overwritten. Because of this, we need to reinit the field
each time we go through the loop. Without this we may receive truncated
messages due to the firmware thinking we have insufficient buffer size.

Change-ID: I21dcca5114d91365d731169965ce3ffec0e4a190
Signed-off-by: NMitch Williams <mitch.a.williams@intel.com>
Signed-off-by: NPatrick Lu <patrick.lu@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

As per the Documentation/timers/timers-howto.txt it is preferred to use
usleep_range() instead of udelay() if the delay value is > 10us in
non-atomic contexts.
So, replacing all the instances of udelay() with 10 or greater than 10
micro seconds delay in the driver and using usleep_range() instead.

Change-ID: Iaa2ab499a4c26f6005e5d86cc421407ef9de16c7
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NNeerav Parikh <neerav.parikh@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

Bump i40e version to 1.0.11 and i40evf version to 1.0.5.

Change-ID: I63a60fa2efe82aae87a8a3095f43218db57d46ce
Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
Tested-by: NJim Young <jamesx.m.young@intel.com>

Bump versions for i40e to 1.0.4 and i40evf to 1.0.1.

Change-ID: I960c04da2c91bdf1d02f8e5011e68c34a634122d
Signed-off-by: NCatherine Sullivan <catherine.sullivan@intel.com>
Tested-By: NJim Young <jamesx.m.young@intel.com>
Tested-by: NSibai Li <sibai.li@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>

We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to
meet kernel coding style guidelines.  This issue was reported by checkpatch.

A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):

// <smpl>

@@
identifier i;
declarer name DEFINE_PCI_DEVICE_TABLE;
initializer z;
@@

- DEFINE_PCI_DEVICE_TABLE(i)
+ const struct pci_device_id i[]
= z;

// </smpl>

[bhelgaas: add semantic patch]
Signed-off-by: NBenoit Taine <benoit.taine@lip6.fr>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

Removing VF driver during device still in reset caused guest OS panic.

in the i40evf_remove(), we're trying to clean mac_filter_list which has
not been initialized since the device is still stuck at the reset.
The change is to initialize the filter_list before setting any task.

Change-ID: I8b59df7384416c7e6f2d264b598f447e1c2c92b0
Signed-off-by: NSerey Kong <serey.kong@intel.com>
Tested-by: NSibai Li <sibai.li@intel.com>
Signed-off-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>