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/net_driver.h b/drivers/net/sfc/net_driver.h
index e8d5f03..c422eb2 100644
--- a/drivers/net/sfc/net_driver.h
+++ b/drivers/net/sfc/net_driver.h
@@ -645,7 +645,7 @@
* @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 @@
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];