All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next] sfc: check warm_boot_count after other functions have been reset
@ 2015-12-04  8:48 Bert Kenward
  2015-12-05 22:59 ` David Miller
  0 siblings, 1 reply; 2+ messages in thread
From: Bert Kenward @ 2015-12-04  8:48 UTC (permalink / raw)
  To: David Miller; +Cc: netdev, Solarflare linux maintainers, Daniel Pieczko

From: Daniel Pieczko <dpieczko@solarflare.com>

A change in MCFW behaviour means that the net driver must update its record
of the warm_boot_count by reading it from the ER_DZ_BIU_MC_SFT_STATUS
register.

On v4.6.x MCFW the global boot count was incremented when some functions
needed to be reset to enable multicast chaining, so all functions saw the
same value.  In that case, the driver needed to increment its
warm_boot_count when other functions were reset, to avoid noticing it later
and then trying to reset itself to recover unnecessarily.

With v4.7+ MCFW, the boot count in firmware doesn't change as that is
unnecessary since the PFs that have been reset will each receive an MC
reboot notification.  In that case, the driver re-reads the unchanged
value.

Signed-off-by: Bert Kenward <bkenward@solarflare.com>
---
 drivers/net/ethernet/sfc/ef10.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 425df3d..c4a0e8a 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -2374,8 +2374,19 @@ static int efx_ef10_ev_init(struct efx_channel *channel)
 				    1 << MC_CMD_WORKAROUND_EXT_OUT_FLR_DONE_LBN) {
 					netif_info(efx, drv, efx->net_dev,
 						   "other functions on NIC have been reset\n");
-					/* MC's boot count has incremented */
-					++nic_data->warm_boot_count;
+
+					/* With MCFW v4.6.x and earlier, the
+					 * boot count will have incremented,
+					 * so re-read the warm_boot_count
+					 * value now to ensure this function
+					 * doesn't think it has changed next
+					 * time it checks.
+					 */
+					rc = efx_ef10_get_warm_boot_count(efx);
+					if (rc >= 0) {
+						nic_data->warm_boot_count = rc;
+						rc = 0;
+					}
 				}
 				nic_data->workaround_26807 = true;
 			} else if (rc == -EPERM) {
-- 
2.4.3

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH net-next] sfc: check warm_boot_count after other functions have been reset
  2015-12-04  8:48 [PATCH net-next] sfc: check warm_boot_count after other functions have been reset Bert Kenward
@ 2015-12-05 22:59 ` David Miller
  0 siblings, 0 replies; 2+ messages in thread
From: David Miller @ 2015-12-05 22:59 UTC (permalink / raw)
  To: bkenward; +Cc: netdev, linux-net-drivers, dpieczko

From: Bert Kenward <bkenward@solarflare.com>
Date: Fri, 4 Dec 2015 08:48:39 +0000

> From: Daniel Pieczko <dpieczko@solarflare.com>
> 
> A change in MCFW behaviour means that the net driver must update its record
> of the warm_boot_count by reading it from the ER_DZ_BIU_MC_SFT_STATUS
> register.
> 
> On v4.6.x MCFW the global boot count was incremented when some functions
> needed to be reset to enable multicast chaining, so all functions saw the
> same value.  In that case, the driver needed to increment its
> warm_boot_count when other functions were reset, to avoid noticing it later
> and then trying to reset itself to recover unnecessarily.
> 
> With v4.7+ MCFW, the boot count in firmware doesn't change as that is
> unnecessary since the PFs that have been reset will each receive an MC
> reboot notification.  In that case, the driver re-reads the unchanged
> value.
> 
> Signed-off-by: Bert Kenward <bkenward@solarflare.com>

Applied, thanks.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-12-05 22:59 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-04  8:48 [PATCH net-next] sfc: check warm_boot_count after other functions have been reset Bert Kenward
2015-12-05 22:59 ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.