1. 04 8月, 2020 1 次提交
  2. 15 7月, 2020 2 次提交
  3. 10 7月, 2020 2 次提交
  4. 31 3月, 2020 2 次提交
  5. 26 2月, 2020 1 次提交
  6. 25 2月, 2020 4 次提交
  7. 24 2月, 2020 5 次提交
  8. 13 11月, 2019 1 次提交
  9. 01 11月, 2019 1 次提交
  10. 07 10月, 2019 1 次提交
  11. 05 10月, 2019 2 次提交
  12. 17 9月, 2019 1 次提交
  13. 22 8月, 2019 2 次提交
  14. 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
  15. 14 6月, 2019 1 次提交
  16. 05 6月, 2019 1 次提交
  17. 19 5月, 2019 1 次提交
  18. 23 4月, 2019 1 次提交
  19. 05 4月, 2019 1 次提交
  20. 29 3月, 2019 2 次提交
  21. 25 3月, 2019 1 次提交
  22. 04 3月, 2019 1 次提交
  23. 14 2月, 2019 1 次提交
  24. 09 2月, 2019 1 次提交
  25. 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
  26. 04 12月, 2018 1 次提交