On Wed, 2019-11-20 at 22:48 +0100, Pavel Machek wrote:
Hi!
[ Upstream commit fd2a981777d911b2e94cdec50779c85c58a0dec9 ]
Once reset is issued, the driver loses all control queue interfaces. Exercising control queue operations during reset is incorrect and may result in long timeouts.
This patch introduces a new field 'reset_ongoing' in the hw structure. This is set to 1 by the core driver when it receives a reset interrupt. ice_sq_send_cmd checks reset_ongoing before actually issuing the control queue operation. If a reset is in progress, it returns a soft error code (ICE_ERR_RESET_PENDING) to the caller. The caller may or may not have to take any action based on this return. Once the driver knows that the reset is done, it has to set reset_ongoing back to 0. This will allow control queue operations to be posted to the hardware again.
This "bail out" logic was specifically added to ice_sq_send_cmd (which is pretty low level function) so that we have one solution in one place that applies to all types of control queues.
I don't think this is suitable for stable. Would driver maintainers comment?
Actually this change is fine for stable.
** As this is the start of the reset/rebuild cycle,set
* both to indicate that.*/hw->reset_ongoing = true;This should be = 1, since variable is u8...
This variable is treated as a bool, and since bools vary depending on architecture, Linus has stated that using a u8 would be more consistent across the vary architectures. So we have used u8's for variables treated as bools.
In addition, there has been no issue assigning "true" or "false" to a u8.
Best regards, Pav el
+++ b/drivers/net/ethernet/intel/ice/ice_type.h @@ -293,6 +293,7 @@ struct ice_hw { u8 sw_entry_point_layer; u8 evb_veb; /* true for VEB, false for VEPA */
- u8 reset_ongoing; /* true if hw is in reset, false otherwise */ struct ice_bus_info bus; struct ice_nvm_info nvm; struct ice_hw_dev_caps dev_caps; /* device capabilities */
--