sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue
authorSteve Hodgson <shodgson@solarflare.com>
Thu, 2 Dec 2010 13:46:55 +0000 (13:46 +0000)
committerDavid S. Miller <davem@davemloft.net>
Fri, 3 Dec 2010 17:08:05 +0000 (09:08 -0800)
commit18e3ee2cf96adf072deeb291eed670f2c23bb2fc
tree50435796fa5d08795e82138c39f50f2b11ec7055
parent3157183a90fdbd686f939d2f032b675f7e9983d6
sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue

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>
Signed-off-by: David S. Miller <davem@davemloft.net>
drivers/net/sfc/mcdi.c