Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753980AbbLBKUM (ORCPT ); Wed, 2 Dec 2015 05:20:12 -0500 Received: from nbfkord-smmo02.seg.att.com ([209.65.160.78]:63816 "EHLO nbfkord-smmo02.seg.att.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751293AbbLBKUK (ORCPT ); Wed, 2 Dec 2015 05:20:10 -0500 X-MXL-Hash: 565ec5d911d7245e-ef5d736974ab86abff23400691bc9cf03e638ef3 X-MXL-Hash: 565ec5d836df6849-2e547604034773ce57affe8e21291fcf40e91035 From: Bert Kenward Subject: [PATCH] sfc: check warm_boot_count after other functions have been reset To: David Miller CC: , Solarflare linux maintainers , Daniel Pieczko Organization: Solarflare Message-ID: <565EC5B8.4060702@solarflare.com> Date: Wed, 2 Dec 2015 10:19:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.17.20.82] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ocex03.SolarFlarecom.com (10.20.40.36) X-AnalysisOut: [v=2.0 cv=SOT1opTH c=1 sm=1 a=8BlWFWvVlq5taO8ncb8nKg==:17 a] X-AnalysisOut: [=zRKbQ67AAAAA:8 a=OjXlt12Agc0A:10 a=wUQvQvOEmiQA:10 a=DHE8] X-AnalysisOut: [91H7Gske2VlohvUA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [12.187.104.26] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2139 Lines: 56 From: Daniel Pieczko 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 --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/