Commit 747df2258b1b9a2e25929ef496262c339c380009 ('sfc: Always map MCDI
shared memory as uncacheable') introduced a separate mapping for the
MCDI shared memory (MC_TREG_SMEM).  This means we can no longer easily
include it in the register dump.  Since it is not particularly useful
in debugging, substitute a recognisable dummy value.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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 <bhutchings@solarflare.com>

Enabling write-combining may also enable read reordering.  The BIU is
only guaranteed to read from a 128-bit CSR or 64-bit SRAM word when
the host reads from its lowest address; otherwise the BIU may use the
latched value.  Therefore we need to reinstate the read memory
barriers after the first read operation for each CSR or SRAM word.

Signed-off-by; Ben Hutchings <bhutchings@solarflare.com>

During self-tests we use efx_process_channel_now() to handle
completion and other events synchronously.  This disables interrupts
and NAPI processing for the channel in question, but it may still be
interrupted by another channel.  A single socket may receive packets
from multiple net devices or even multiple channels of the same net
device, so this can result in deadlock on a socket lock.

Receiving packets in process context will also result in incorrect
classification by the network cgroup classifier.

Therefore, we must only use efx_process_channel_now() in the offline
loopback tests (which never deliver packets up the stack) and not for
the online interrupt and event tests.

For the interrupt test, there is no reason to process events.  We
only care that an interrupt is raised.

For the event test, we want to know whether events have been received,
and there may be many events ahead of the one we inject.  Therefore
remove efx_channel::magic_count and instead test whether
efx_channel::eventq_read_ptr advances.  This is currently an event
queue index and might wrap around to exactly the same value, resulting
in a false negative.  Therefore move the masking to efx_event() and
efx_nic_eventq_read_ack() so that it cannot wrap within the time of
the test.

The event test also tries to diagnose failures by checking whether an
event was delivered without causing an interrupt.  Add and use a
helper function that only does this.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

If the TX queues are running during loopback self tests, host
traffic gets looped back which causes the test to fail.  Avoid
restarting the TX queues after the port reset so that any packets
sent by the host get held back until after the tests have completed.

[bwh: Also wake all TX queues at the end of self-tests.]

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>

If SR-IOV is enabled by firmware, even if it is not enabled in the PCI
capability, TX pushes using write-combining may be corrupted.

We want to know whether it is enabled before mapping the NIC
registers, and even if PCI extended capabilities are not accessible.
Therefore, we look for the MSI capability, which is removed if SR-IOV
is enabled.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

Based on work by Neil Turton <nturton@solarflare.com> and
Kieran Mansley <kmansley@solarflare.com>.

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 <bhutchings@solarflare.com>

Conflicts:
	drivers/net/bnx2x/bnx2x.h