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>
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 60176e8..a4c7830 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -536,7 +536,7 @@
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;