linux-toradex.git/drivers/net/sfc/mcdi.c, branch v3.0.40

Revert "sfc: Use write-combining to reduce TX latency" and follow-ups

2011-10-03T18:40:53+00:00

[ Upstream commit 86c432ca5d6da90a26ac8d3e680f2268b502d9c5 ]

This reverts commits 65f0b417dee94f779ce9b77102b7d73c93723b39,
d88d6b05fee3cc78e5b0273eb58c31201dcc6b76,
fcfa060468a4edcf776f0c1211d826d5de1668c1,
747df2258b1b9a2e25929ef496262c339c380009 and
867955f5682f7157fdafe8670804b9f8ea077bc7.

Depending on the processor model, write-combining may result in
reordering that the NIC will not tolerate.  This typically results
in a DMA error event and reset by the driver, logged as:

sfc 0000:0e:00.0: eth2: TX DMA Q reports TX_EV_PKT_ERR.
sfc 0000:0e:00.0: eth2: resetting (ALL)

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sfc: Always map MCDI shared memory as uncacheable

2011-05-12T14:16:32+00:00

We enabled write-combining for memory-mapped registers in commit
65f0b417dee94f779ce9b77102b7d73c93723b39, but inhibited it for the
MCDI shared memory where this is not supported.  However,
write-combining mappings also allow read-reordering, which may also
be a problem.

I found that when an SFC9000-family controller is connected to an
Intel 3000 chipset, and write-combining is enabled, the controller
stops responding to PCIe read requests during driver initialisation
while the driver is polling for completion of an MCDI command.  This
results in an NMI and system hang.  Adding read memory barriers
between all reads to the shared memory area appears to reduce but not
eliminate the probability of this.

We have not yet established whether this is a bug in our BIU or in the
PCIe bridge.  For now, work around by mapping the shared memory area
separately.

Signed-off-by: Ben Hutchings

Fix common misspellings

2011-03-31T14:26:23+00:00

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi

sfc: Use write-combining to reduce TX latency

2011-03-04T17:58:42+00:00

Based on work by Neil Turton  and
Kieran Mansley .

The BIU has now been verified to handle 3- and 4-dword writes within a
single 128-bit register correctly.  This means we can enable write-
combining and only insert write barriers between writes to distinct
registers.

This has been observed to save about 0.5 us when pushing a TX
descriptor to an empty TX queue.

Signed-off-by: Ben Hutchings

sfc: Update copyright dates

2011-02-28T23:57:24+00:00

Signed-off-by: Ben Hutchings

sfc: Read MC firmware version when requested through ethtool

2011-02-28T23:57:23+00:00

We currently make no use of siena_nic_data::fw_{version,build} except
to format the firmware version for ethtool_get_drvinfo().  Since we
only read the version at start of day, this information is incorrect
after an MC firmware update.  Remove the cached version information
and read it via MCDI whenever it is requested.

Signed-off-by: Ben Hutchings

sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issue

2010-12-03T17:08:05+00:00

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 
Signed-off-by: David S. Miller

sfc: Reduce log level for MCDI error response in efx_mcdi_rpc()

2010-12-03T17:08:02+00:00

Some errors are expected, e.g. when sending new commands to an MC
running old firmware.  Only the caller of efx_mcdi_rpc() can decide
what is a real error.  Therefore log the error responses with
netif_dbg().

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller

sfc: make functions static

2010-10-21T10:09:43+00:00

Make local functions and variable static. Do some rearrangement
of the string table stuff to put it where it gets used.

Signed-off-by: Stephen Hemminger 
Acked-by: Ben Hutchings 
Signed-off-by: David S. Miller

sfc: Implement message level control

2010-06-25T05:13:22+00:00

Replace EFX_ERR() with netif_err(), EFX_INFO() with netif_info(),
EFX_LOG() with netif_dbg() and EFX_TRACE() and EFX_REGDUMP() with
netif_vdbg().

Replace EFX_ERR_RL(), EFX_INFO_RL() and EFX_LOG_RL() using explicit
calls to net_ratelimit().

Implement the ethtool operations to get and set message level flags,
and add a 'debug' module parameter for the initial value.

Signed-off-by: Ben Hutchings 
Signed-off-by: David S. Miller