]> www.infradead.org Git - users/jedix/linux-maple.git/commit
i40evf: handle big resets
authorMitch Williams <mitch.a.williams@intel.com>
Thu, 4 Jun 2015 20:23:58 +0000 (16:23 -0400)
committerBrian Maly <brian.maly@oracle.com>
Mon, 31 Aug 2015 19:32:36 +0000 (15:32 -0400)
commit34582f7967685e36cbf116c6ae15cb11665b14b5
tree0f3b94a3ceee5699175af6868c557249d8e0d03c
parent55f00b06e6abcafb8d0ea0e36448e757c34696b1
i40evf: handle big resets

Orabug: 21764569

The most common type of reset that the VF will encounter is a PF reset
that cascades down into a VF reset for each VF. In this case, the VF
will always be assigned the same VSI and recovery is fairly simple.

However, in the case of 'bigger' resets, such as a Core or EMP reset,
when the device is reinitialized, it's probable that the VF will NOT get
the same VSI. When this happens, the VF will not be able to recover, as
it will continue to request resources for its original VSI.

Add an extra state to the admin queue state machine so that the driver
can re-request its configuration information at runtime. During reset
recovery, set this bit in the aq_required field, and fetch the (possibly
new) configuration information before attempting to bring the driver
back up. Since the driver doesn't know what kind of reset it has
encountered, this step is done even for a PF reset, but it doesn't hurt
anything - it just gets the same VSI back.

Change-ID: I915d59ffb40375215117362f4ac7a37811aba748
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from commit e6d038de13c82f8446d9db5b3d9bb7788344b2bd)
Signed-off-by: Brian Maly <brian.maly@oracle.com>
drivers/net/ethernet/intel/i40evf/i40evf.h
drivers/net/ethernet/intel/i40evf/i40evf_main.c
drivers/net/ethernet/intel/i40evf/i40evf_virtchnl.c