1. 15 3月, 2018 1 次提交
    • E
      sfc: support FEC configuration through ethtool · 7f61e6c6
      Edward Cree 提交于
      As well as 'auto' and the forced 'off', 'rs' and 'baser' states, we also
       handle combinations of settings (since the fecparam->fec field is a
       bitmask), where auto|rs and auto|baser specify a preferred FEC mode but
       will fall back to the other if the cable or link partner doesn't support
       it.  rs|baser (with or without auto bit) means prefer FEC even where
       auto wouldn't use it, but let FW choose which encoding to use.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f61e6c6
  2. 09 3月, 2018 1 次提交
  3. 26 1月, 2018 2 次提交
  4. 11 1月, 2018 1 次提交
  5. 22 12月, 2017 1 次提交
  6. 19 12月, 2017 3 次提交
  7. 15 2月, 2017 1 次提交
  8. 10 2月, 2017 3 次提交
  9. 03 2月, 2017 1 次提交
  10. 18 1月, 2017 2 次提交
  11. 17 1月, 2017 1 次提交
    • 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
  12. 11 1月, 2017 1 次提交
  13. 05 1月, 2017 1 次提交
  14. 18 12月, 2016 1 次提交
  15. 04 12月, 2016 1 次提交
  16. 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
  17. 28 11月, 2016 1 次提交
  18. 19 11月, 2016 2 次提交
    • E
      sfc: remove Software TSO · 46d1efd8
      Edward Cree 提交于
      It gives no advantage over GSO now that xmit_more exists.  If we find
       ourselves unable to handle a TSO skb (because our TXQ doesn't have a
       TSOv2 context and the NIC doesn't support TSOv1), hand it back to GSO.
       Also do that if the TSO handler fails with EINVAL for any other reason.
      As Falcon-architecture NICs don't support any firmware-assisted TSO,
       they no longer advertise TSO feature flags at all.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      46d1efd8
    • B
      sfc: Firmware-Assisted TSO version 2 · e9117e50
      Bert Kenward 提交于
      Add support for FATSOv2 to the driver. FATSOv2 offloads far more of the task
       of TCP segmentation to the firmware, such that we now just pass a single
       super-packet to the NIC. This means TSO has a great deal in common with a
       normal DMA transmit, apart from adding a couple of option descriptors.
       NIC-specific checks have been moved off the fast path and in to
       initialisation where possible.
      
      This also moves FATSOv1/SWTSO to a new file (tx_tso.c).  The end of transmit
       and some error handling is now outside TSO, since it is common with other
       code.
      Signed-off-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e9117e50
  19. 10 11月, 2016 1 次提交
  20. 07 9月, 2016 1 次提交
  21. 27 8月, 2016 1 次提交
  22. 13 8月, 2016 2 次提交
  23. 16 6月, 2016 4 次提交
  24. 01 6月, 2016 1 次提交
  25. 03 12月, 2015 1 次提交
  26. 02 12月, 2015 1 次提交
  27. 03 11月, 2015 1 次提交
  28. 28 10月, 2015 1 次提交
  29. 12 10月, 2015 1 次提交
    • D
      sfc: fully reset if MC_REBOOT event received without warm_boot_count increment · c577e59e
      Daniel Pieczko 提交于
      On EF10, MC_CMD_VPORT_RECONFIGURE can cause a CODE_MC_REBOOT event
      to be sent to a function without incrementing the (adapter-wide)
      warm_boot_count.  In this case, the reboot is not detected by the
      loop on efx_mcdi_poll_reboot(), so prepare for recovery from an MC
      reboot anyway.  When this codepath is run, the MC has always just
      rebooted, so this recovery is valid.
      
      The loop on efx_mcdi_poll_reboot() is still required for other MC
      reboot cases, so that actions in response to an MC reboot are
      performed, such as clearing locally calculated statistics.
      Siena NICs are unaffected by this change as the above scenario
      does not apply.
      Signed-off-by: NShradha Shah <sshah@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c577e59e