1. 02 7月, 2019 2 次提交
    • P
      mlxsw: pci: PTP: Hook into packet transmit path · 0714256c
      Petr Machata 提交于
      On Spectrum-1, timestamps are delivered separately from the packets, and
      need to paired up. Therefore, at some point after mlxsw_sp_port_xmit()
      is invoked, it is necessary to involve the chip-specific driver code to
      allow it to do the necessary bookkeeping and matching.
      
      On Spectrum-2, timestamps are delivered in CQE. For that reason,
      position the point of driver involvement into mlxsw_pci_cqe_sdq_handle()
      to make it hopefully easier to extend for Spectrum-2 in the future.
      
      To tell the driver what port the packet was sent on, keep tx_info
      in SKB control buffer.
      
      Introduce a new driver core interface mlxsw_core_ptp_transmitted(), a
      driver callback ptp_transmitted, and a PTP op transmitted. The callee is
      responsible for taking care of releasing the SKB passed to the new
      interfaces, and correspondingly have the new stub callbacks just call
      dev_kfree_skb_any().
      
      Follow-up patches will introduce the actual content into
      mlxsw_sp1_ptp_transmitted() in particular.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0714256c
    • P
      mlxsw: core: Add support for using SKB control buffer · d7cd206d
      Petr Machata 提交于
      The SKB control buffer is useful (and used) for bookkeeping of information
      related to that SKB. Add helpers so that the mlxsw driver(s) can safely use
      the buffer as well. The structure is currently empty, individual users will
      add members to it as necessary.
      
      Note that SKB allocation functions already clear the buffer, so the cleanup
      is only necessary when ndo_start_xmit is called.
      Signed-off-by: NPetr Machata <petrm@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d7cd206d
  2. 14 6月, 2019 1 次提交
  3. 05 6月, 2019 1 次提交
  4. 19 5月, 2019 1 次提交
  5. 23 4月, 2019 1 次提交
  6. 05 4月, 2019 1 次提交
  7. 29 3月, 2019 2 次提交
  8. 25 3月, 2019 1 次提交
  9. 04 3月, 2019 1 次提交
  10. 14 2月, 2019 1 次提交
  11. 09 2月, 2019 1 次提交
  12. 19 12月, 2018 1 次提交
    • S
      mlxsw: core: Increase timeout during firmware flash process · cf0b70e7
      Shalom Toledo 提交于
      During the firmware flash process, some of the EMADs get timed out, which
      causes the driver to send them again with a limit of 5 retries. There are
      some situations in which 5 retries is not enough and the EMAD access fails.
      If the failed EMAD was related to the flashing process, the driver fails
      the flashing.
      
      The reason for these timeouts during firmware flashing is cache misses in
      the CPU running the firmware. In case the CPU needs to fetch instructions
      from the flash when a firmware is flashed, it needs to wait for the
      flashing to complete. Since flashing takes time, it is possible for pending
      EMADs to timeout.
      
      Fix by increasing EMADs' timeout while flashing firmware.
      
      Fixes: ce6ef68f ("mlxsw: spectrum: Implement the ethtool flash_device callback")
      Signed-off-by: NShalom Toledo <shalomt@mellanox.com>
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cf0b70e7
  13. 04 12月, 2018 1 次提交
  14. 18 10月, 2018 1 次提交
  15. 10 8月, 2018 2 次提交
  16. 06 6月, 2018 1 次提交
  17. 29 5月, 2018 1 次提交
  18. 20 5月, 2018 2 次提交
  19. 01 4月, 2018 4 次提交
  20. 17 1月, 2018 4 次提交
  21. 26 5月, 2017 1 次提交
  22. 25 3月, 2017 1 次提交
  23. 07 2月, 2017 1 次提交
  24. 04 12月, 2016 1 次提交
    • I
      mlxsw: core: Create an ordered workqueue for FIB offload · a3832b31
      Ido Schimmel 提交于
      We're going to start processing FIB entries addition / deletion events
      in deferred work. These work items must be processed in the order they
      were submitted or otherwise we can have differences between the kernel's
      FIB table and the device's.
      
      Solve this by creating an ordered workqueue to which these work items
      will be submitted to. Note that we can't simply convert the current
      workqueue to be ordered, as EMADs re-transmissions are also processed in
      deferred work.
      
      Later on, we can migrate other work items to this workqueue, such as FDB
      notification processing and nexthop resolution, since they all take the
      same lock anyway.
      Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a3832b31
  25. 26 11月, 2016 6 次提交