- 21 8月, 2013 6 次提交
-
-
由 Ben Hutchings 提交于
No need to keep open-coding the assignment of high and low dwords. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
We currently require that MCDI request and response lengths are multiples of 4 bytes, because we will copy dwords in and out of shared memory and we want to be sure we won't read or write out of bounds. But all we really need to know is that there is sufficient padding for that. Also, we should ensure that buffers are dword-aligned, as on some architectures misaligned access will result in data corruption or a crash. Change the buffer type to array-of-efx_dword_t and remove the requirement that the lengths are multiples of 4. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
A few functions are using heap buffers; change them to use stack buffers as we really don't need to resort to the heap for a 252 byte buffer in process context. MC_CMD_MEMCPY is quite weird in that it can use inline data placed in the request buffer after the array of records. Thus there are two variable-length arrays and we can't use the normal accessors for the second. So we have to use _MCDI_PTR() in efx_sriov_memcpy(). Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
We need to access arrays of 16-bit words and 32-bit dwords in MCDI buffers based on the MCDI protocol definitions. We should also be able to read and write fields within structures, without specifying an array index each time. So add MCDI_FIELD() and make MCDI_ARRAY_FIELD() use it. Also add MCDI_SET_FIELD(). Split MCDI_ARRAY_PTR() into MCDI_ARRAY_STRUCT_PTR() and _MCDI_ARRAY_PTR(), which are currently identical but will diverge in later changes. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
Add _MCDI_DWORD() which yields an lvalue for the given dword field and change MCDI_DWORD(), MCDI_SET_DWORD() and MCDI_QWORD() to use it. Fold the rather trivial MCDI_PTR2() into MCDI_PTR() and _MCDI_DWORD(). Remove MCDI_SET_DWORD2() and MCDI_QWORD2(). MCDI_DWORD2() should also go, but it still has one user which we'll get rid of later. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
MCDI_DECLARE_BUF declares a variable as an MCDI buffer of the requested length, adding any necessary padding. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
- 02 10月, 2012 1 次提交
-
-
由 Ben Hutchings 提交于
The least significant bit number (LBN) of a field within an MCDI structure is counted from the start of the structure, not the containing dword. In MCDI_ARRAY_FIELD() we need to mask it rather than using the usual EFX_DWORD_FIELD() macro. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
- 08 9月, 2012 1 次提交
-
-
由 Stuart Hodgson 提交于
For NIC/System time synchonisation efx_mcdi_rpc needs to be split in efx_mcdi_rpc_start and efx_mcdi_rpc_finish operations. Signed-off-by: NStuart Hodgson <smhodgson@solarflare.com> Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
- 16 2月, 2012 1 次提交
-
-
由 Ben Hutchings 提交于
On the SFC9000 family, each port has 1024 Virtual Interfaces (VIs), each with an RX queue, a TX queue, an event queue and a mailbox register. These may be assigned to up to 127 SR-IOV virtual functions per port, with up to 64 VIs per VF. We allocate an extra channel (IRQ and event queue only) to receive requests from VF drivers. There is a per-port limit of 4 concurrent RX queue flushes, and queue flushes may be initiated by the MC in response to a Function Level Reset (FLR) of a VF. Therefore, when SR-IOV is in use, we submit all flush requests via the MC. The RSS indirection table is shared with VFs, so the number of RX queues used in the PF is limited to the number of VIs per VF. This is almost entirely the work of Steve Hodgson, formerly shodgson@solarflare.com. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
- 27 1月, 2012 3 次提交
-
-
由 Ben Hutchings 提交于
The SFC9000-family controllers have firmware to manage all board peripherals including temperature, heat sink continuity and voltage sensors. The firmware reports sensor alarms, which we log, and will shut down the board if necessary. Some users may want to monitor their boards more closely, so add an hwmon driver that exposes all sensors reported by the firmware. Move efx_mcdi_sensor_event() into the new file so it can share the array of sensor labels with the hwmon driver. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Matthew Slattery 提交于
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben Hutchings 提交于
No NICs need to switch efx_mac_operations at run-time, and the MAC operations are fairly closely bound to NIC types. Move efx_mac_operations::reconfigure to efx_nic_type::reconfigure_mac and efx_mac_operations::check_fault fo efx_nic_type::check_mac_fault. Change callers to call through efx->type or directly if the NIC type is known. Remove efx_mac_operations::update_stats. The implementations for Falcon used to fetch MAC statistics synchronously and this was used by efx_register_netdev() to clear statistics after running self-tests. However, it now only converts statistics that have already been fetched (and that only for Falcon), and the call from efx_register_netdev() has no effect. Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
- 11 8月, 2011 1 次提交
-
-
由 Jeff Kirsher 提交于
Moves the Solarflare drivers into drivers/net/ethernet/sfc/ and make the necessary Kconfig and Makefile changes. CC: Steve Hodgson <shodgson@solarflare.com> CC: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
-
- 01 3月, 2011 2 次提交
-
-
由 Ben Hutchings 提交于
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
-
由 Ben 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: NBen Hutchings <bhutchings@solarflare.com>
-
- 21 10月, 2010 1 次提交
-
-
由 stephen 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: NStephen Hemminger <shemminger@vyatta.com> Acked-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 04 2月, 2010 1 次提交
-
-
由 Ben Hutchings 提交于
Signed-off-by: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 26 1月, 2010 1 次提交
-
-
由 Ben 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: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 30 11月, 2009 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: NBen Hutchings <bhutchings@solarflare.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-