sfc: Allow resets to be upgraded; use atomic ops for safety

Currently an attempt to schedule any reset is ignored if a reset
is already pending.  This ignores the relative scopes - if the
requested reset is greater in scope then the scheduled reset should
be upgraded accordingly.

There are also some race conditions which could lead to a reset
request being lost.  Deal with them by using atomic operations on a
bitmask.  This also makes tests on reset_pending easier to get right.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

1 files changed, 1 insertions, 1 deletions

diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 60176e873d62..a4c7830ec9b0 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -536,7 +536,7 @@ void falcon_reconfigure_mac_wrapper(struct efx_nic *efx)
         efx_oword_t reg;
         int link_speed, isolate;
 
-        isolate = (efx->reset_pending != RESET_TYPE_NONE);
+        isolate = !!ACCESS_ONCE(efx->reset_pending);
 
         switch (link_state->speed) {
         case 10000: link_speed = 3; break;