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, 2 insertions, 2 deletions

diff --git a/drivers/net/sfc/net_driver.h b/drivers/net/sfc/net_driver.h
index e8d5f03a89fe..c422eb2ce60a 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -645,7 +645,7 @@ struct efx_filter_state;
  * @irq_rx_moderation: IRQ moderation time for RX event queues
  * @msg_enable: Log message enable flags
  * @state: Device state flag. Serialised by the rtnl_lock.
- * @reset_pending: Pending reset method (normally RESET_TYPE_NONE)
+ * @reset_pending: Bitmask for pending resets
  * @tx_queue: TX DMA queues
  * @rx_queue: RX DMA queues
  * @channel: Channels
@@ -728,7 +728,7 @@ struct efx_nic {
         u32 msg_enable;
 
         enum nic_state state;
-        enum reset_type reset_pending;
+        unsigned long reset_pending;
 
         struct efx_channel *channel[EFX_MAX_CHANNELS];
         char channel_name[EFX_MAX_CHANNELS][IFNAMSIZ + 6];