Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 2月, 2017 1 次提交
  3. 12 2月, 2017 1 次提交
  5. 10 2月, 2017 6 次提交
  7. 08 2月, 2017 1 次提交
  9. 07 2月, 2017 1 次提交
  11. 03 2月, 2017 2 次提交
  13. 01 2月, 2017 1 次提交
  15. 31 1月, 2017 1 次提交
  17. 28 1月, 2017 3 次提交
  19. 26 1月, 2017 1 次提交
  21. 18 1月, 2017 2 次提交
  23. 17 1月, 2017 3 次提交
    • E
      sfc: get PIO buffer size from the NIC · c634700f
      由 Edward Cree 提交于 
      The 8000 series SFC NICs have 4K PIO buffers, rather than the 2K of
 the 7000 series.  Rather than having a hard-coded PIO buffer size
 (ER_DZ_TX_PIOBUF_SIZE), read it from the GET_CAPABILITIES_V2 MCDI
 response.
Signed-off-by: NEdward Cree <ecree@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c634700f
    • E
      sfc: allow PIO more often · de1deff9
      由 Edward Cree 提交于 
      If an option descriptor has been sent on a queue but not followed by a
 packet, there will have been no completion event, so the read and write
 counts won't match and we'll think we can't do PIO.  This combines with
 the fact that we have two TX queues (for en/disable checksum offload),
 and that both must be empty for PIO to happen.
This patch adds a separate "packet_write_count" that tracks the most
 recent write_count we expect to see a completion event for; this excludes
 option descriptors but _includes_ PIO descriptors (even though they look
 like option descriptors).  This is then used, rather than write_count,
 in efx_nic_tx_is_empty().
We only bother to maintain packet_write_count on EF10, since on Siena
 (a) there are no option descriptors and it always equals write_count, and
 (b) there's no PIO, so we don't need it anyway.
Signed-off-by: NEdward Cree <ecree@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de1deff9
    • S
      sfc: Replace memset with eth_zero_addr · 4b5b1ac5
      由 Shyam Saini 提交于 
      Use eth_zero_addr to assign zero address to the given address array
instead of memset when the second argument in memset is address
of zero which makes the code clearer and also add header
file linux/etherdevice.h
Signed-off-by: NShyam Saini <mayhs11saini@gmail.com>
Acked-by: NEdward Cree <ecree@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4b5b1ac5
  25. 12 1月, 2017 1 次提交
  27. 11 1月, 2017 3 次提交
  29. 09 1月, 2017 1 次提交
  31. 05 1月, 2017 1 次提交
  33. 03 1月, 2017 3 次提交
  35. 21 12月, 2016 1 次提交
  37. 18 12月, 2016 1 次提交
  39. 04 12月, 2016 1 次提交
  41. 02 12月, 2016 3 次提交
  43. 30 11月, 2016 1 次提交
    • E
      sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver · 5a6681e2
      由 Edward Cree 提交于 
      Rationale: The differences between Falcon and Siena are in many ways larger
 than those between Siena and EF10 (despite Siena being nominally "Falcon-
 architecture"); for instance, Falcon has no MCPU, so there is no MCDI.
 Removing Falcon support from the sfc driver should simplify the latter,
 and avoid the possibility of Falcon support being broken by changes to sfc
 (which are rarely if ever tested on Falcon, it being end-of-lifed hardware).

The sfc-falcon driver created in this changeset is essentially a copy of the
 sfc driver, but with Siena- and EF10-specific code, including MCDI, removed
 and with the "efx_" identifier prefix changed to "ef4_" (for "EFX 4000-
 series") to avoid collisions when both drivers are built-in.

This changeset removes Falcon from the sfc driver's PCI ID table; then in
 sfc I've removed obvious Falcon-related code: I removed the Falcon NIC
 functions, Falcon PHY code, and EFX_REV_FALCON_*, then fixed up everything
 that referenced them.

Also, increment minor version of both drivers (to 4.1).

For now, CONFIG_SFC selects CONFIG_SFC_FALCON, so that updating old configs
 doesn't cause Falcon support to disappear; but that should be undone at
 some point in the future.
Signed-off-by: NEdward Cree <ecree@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a6681e2
  45. 28 11月, 2016 1 次提交