aboutsummaryrefslogtreecommitdiff
path: root/drivers/net/sfc/mcdi.c
AgeCommit message (Collapse)Author
2011-10-03Revert "sfc: Use write-combining to reduce TX latency" and follow-upsBen Hutchings
[ 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 <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2011-05-12sfc: Always map MCDI shared memory as uncacheableBen Hutchings
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>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-04sfc: Use write-combining to reduce TX latencyBen Hutchings
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>
2011-02-28sfc: Update copyright datesBen Hutchings
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
2011-02-28sfc: Read MC firmware version when requested through ethtoolBen Hutchings
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 <bhutchings@solarflare.com>
2010-12-03sfc: Fix event based MCDI completion and MC REBOOT/CMDDONE ordering issueSteve Hodgson
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>
2010-12-03sfc: Reduce log level for MCDI error response in efx_mcdi_rpc()Ben Hutchings
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 <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-21sfc: make functions staticstephen hemminger
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 <shemminger@vyatta.com> Acked-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-06-24sfc: Implement message level controlBen Hutchings
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 <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-28sfc: Log specific message for failure of NVRAM self-testBen Hutchings
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-04-28sfc: Consistently report short MCDI responses as EIOBen Hutchings
In some cases failing functions were returning 0 which is obviously wrong. In other cases they were returning inappropriate error codes. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-25Merge branch 'master' of ↵David S. Miller
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
2010-02-19sfc: Fix sign of efx_mcdi_poll_reboot() error in efx_mcdi_poll()Ben Hutchings
efx_mcdi_poll() uses positive error numbers, matching the MCDI protocol. It must negate the result of efx_mcdi_poll_reboot() which returns the usual negative error numbers. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-03sfc: Implement NVRAM selftest for SFC9000 familyBen Hutchings
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-02-03sfc: Handle firmware assertion failure while resettingSteve Hodgson
This allows the driver to recover if the MC firmware has crashed due to an assertion failure. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-25sfc: Use fixed-size buffers for MCDI NVRAM requestsBen Hutchings
The low-level MCDI code always uses 32-bit MMIO operations, and callers must pad input and output buffers to multiples of 4 bytes. The MCDI NVRAM functions are not doing this. Also, their buffers are declared as variable-length arrays with no explicit maximum length. Switch to a fixed buffer size based on the chunk size used by the MTD driver (which is a multiple of 4). Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-01-13sfc: Fix polling for slow MCDI operationsBen Hutchings
When the interface is down and we are using polled mode for MCDI operations, we busy-wait for completion for approximately 1 jiffy using udelay() and then back off to schedule(). But the completion will not wake the task, since we are using polled mode! We must use schedule_timeout_uninterruptible() instead. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-11-29sfc: Add support for SFC9000 family (1)Ben Hutchings
This adds support for the SFC9000 family of 10G Ethernet controllers and LAN-on-motherboard chips, starting with the SFL9021 'Siena' and SFC9020 'Bethpage'. The SFC9000 family is based on the SFC4000 'Falcon' architecture, but with some significant changes: - Two ports are associated with two independent PCI functions (except SFC9010) - Integrated 10GBASE-T PHY(s) (SFL9021/9022) - MAC, PHY and board peripherals are managed by firmware - Driver does not require board-specific code - Firmware supports wake-on-LAN and lights-out management through NC-SI - IPv6 checksum offload and RSS - Filtering by MAC address and VLAN (not included in this code) - PCI SR-IOV (not included in this code) Credit for this code is largely due to my colleagues at Solarflare: Guido Barzini Steve Hodgson Kieran Mansley Matthew Slattery Neil Turton Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>