netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ben Hutchings <bhutchings@solarflare.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, linux-net-drivers@solarflare.com
Subject: [PATCH net-next-2.6 06/17] sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue
Date: Thu, 02 Dec 2010 23:46:55 +0000	[thread overview]
Message-ID: <1291333615.3259.29.camel@bwh-desktop> (raw)
In-Reply-To: <1291333490.3259.23.camel@bwh-desktop>

From: Steve Hodgson <shodgson@solarflare.com>

The mcfw *never* sends CMDDONE when rebooting. Changing this so that it always
sends CMDDONE *before* REBOOT is easy on Siena, but it's not obvious that we
could guarantee to be able to implement this on future hardware.

Given this, I'm less convinced that the protocol should be changed.

To reiterate the failure mode: The driver sees this:

 issue command
 receive REBOOT event

Was that reboot event sent before the command was issued, or in
response to the command? If the former then there will be a subsequent
CMDDONE event, if the latter, then there will be no CMDDONE event.

Options to resolve this are:

 1. REBOOT always completes an outstanding mcdi request, and we set
    the credits count to ignore a subsequent CMDDONE event with
    mismatching seqno.

 2. REBOOT never completes an outstanding mcdi request. If there is
    no CMDDONE event then we rely on the mcdi timeout code to complete
    the outstanding request, incurring a 10s delay.

I'd argue that (2) is tidier, but that incurring a 10s delay is a little
needless. Let's go with (1).

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
---
 drivers/net/sfc/mcdi.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/sfc/mcdi.c b/drivers/net/sfc/mcdi.c
index e389ac6..b716e82 100644
--- a/drivers/net/sfc/mcdi.c
+++ b/drivers/net/sfc/mcdi.c
@@ -463,6 +463,7 @@ static void efx_mcdi_ev_death(struct efx_nic *efx, int rc)
 		if (mcdi->mode == MCDI_MODE_EVENTS) {
 			mcdi->resprc = rc;
 			mcdi->resplen = 0;
+			++mcdi->credits;
 		}
 	} else
 		/* Nobody was waiting for an MCDI request, so trigger a reset */
-- 
1.7.3.2



-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.


  parent reply	other threads:[~2010-12-02 23:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-02 23:44 sfc: Bug fixes and cleanup Ben Hutchings
2010-12-02 23:46 ` [PATCH net-next-2.6 01/17] sfc: Reduce log level for MCDI error response in efx_mcdi_rpc() Ben Hutchings
2010-12-03 17:08   ` David Miller
2010-12-02 23:46 ` [PATCH net-next-2.6 02/17] sfc: Fix condition for no-op in set_phy_flash_cfg() Ben Hutchings
2010-12-03 17:08   ` David Miller
2010-12-02 23:46 ` [PATCH net-next-2.6 03/17] sfc: Distinguish critical and non-critical over-temperature conditions Ben Hutchings
2010-12-03 17:08   ` David Miller
2010-12-02 23:46 ` [PATCH net-next-2.6 04/17] sfc: Read-to-clear LM87 alarm/interrupt status at start of day Ben Hutchings
2010-12-03 17:08   ` David Miller
2010-12-02 23:46 ` [PATCH net-next-2.6 05/17] sfc: Clear RXIN_SEL when soft-resetting QT2025C Ben Hutchings
2010-12-03 17:08   ` David Miller
2010-12-02 23:46 ` Ben Hutchings [this message]
2010-12-03 17:09   ` [PATCH net-next-2.6 06/17] sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 07/17] sfc: Remove broken automatic fallback for invalid Falcon chip/board config Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 08/17] sfc: Expose Falcon BootROM config through MTD, not ethtool Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 09/17] sfc: Remove unnecessary inclusion of various private header files Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 10/17] sfc: Move SPI state to struct falcon_nic_data Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 11/17] sfc: Move mdio_lock " Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 12/17] sfc: Move Falcon global event handling to falcon.c Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 13/17] sfc: Move xmac_poll_required into struct falcon_nic_data Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:47 ` [PATCH net-next-2.6 14/17] sfc: Update kernel-doc to match earlier move of Toeplitz hash key Ben Hutchings
2010-12-03 17:09   ` David Miller
2010-12-02 23:48 ` [PATCH net-next-2.6 15/17] sfc: When waking a stopped tx_queue, only lock that tx_queue Ben Hutchings
2010-12-03 17:10   ` David Miller
2010-12-02 23:48 ` [PATCH net-next-2.6 16/17] sfc: Use current MAC address, not NVRAM MAC address, for WoL filter Ben Hutchings
2010-12-03 17:10   ` David Miller
2010-12-02 23:48 ` [PATCH net-next-2.6 17/17] sfc: Store MAC address from NVRAM in net_device::perm_addr Ben Hutchings
2010-12-03 17:10   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1291333615.3259.29.camel@bwh-desktop \
    --to=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=linux-net-drivers@solarflare.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).