1. 25 10月, 2021 3 次提交
    • G
      net: hns3: add support pause/pfc durations for mac statistics · c8af2887
      Guangbin Huang 提交于
      The mac statistics add pause/pfc durations in device version V3, we can
      get total active cycle of pause/pfc from these durations.
      
      As driver gets register number from firmware to calculate desc number to
      query mac statistics, it needs to set mac statistics extended enable bit
      in firmware command 0x701A to tell firmware that driver supports extended
      mac statistics, otherwise firmware only returns register number of
      version V1.
      
      As pause/pfc durations are not supported by hardware of old version, they
      should not been shown in command "ethtool -S ethX" in this case, so add
      checking max register number of each mac statistic in their version.
      If the max register number of one mac statistic is greater than register
      number got from firmware, it means hardware does not support this mac
      statistic, so ignore this statistic when get string and data of mac
      statistic.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c8af2887
    • G
      net: hns3: device specifications add number of mac statistics · 4e4c03f6
      Guangbin Huang 提交于
      Currently, driver queries number of mac statistics before querying mac
      statistics. As the number of mac statistics is a fixed value in firmware,
      it is redundant to query this number everytime before querying mac
      statistics, it can just be queried once in initialization process and
      saved in device specifications.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e4c03f6
    • G
      net: hns3: modify mac statistics update process for compatibility · 0bd7e894
      Guangbin Huang 提交于
      After querying mac statistics from firmware, driver copies data from
      descriptors to struct mac_stats of hdev, and the number of copied data
      is just according to the register number queried from firmware. There is
      a problem that if the register number queried from firmware is larger
      than data number of struct mac_stats, it will cause a copy overflow.
      
      So if the firmware adds more mac statistics in later version, it is not
      compatible with driver of old version.
      
      To fix this problem, the number of copied data needs to be used the
      minimum value between the register number queried from firmware and
      data number of struct mac_stats.
      
      The first descriptor has three data and there is one reserved, to
      optimize the copy process, add this reserverd data to struct mac_stats.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0bd7e894
  2. 20 10月, 2021 1 次提交
  3. 15 10月, 2021 1 次提交
  4. 29 9月, 2021 2 次提交
  5. 20 9月, 2021 5 次提交
  6. 14 9月, 2021 2 次提交
    • G
      net: hns3: PF support get multicast MAC address space assigned by firmware · 5c56ff48
      Guangbin Huang 提交于
      The new firmware supports to divides the whole multicast MAC address space
      equally to functions of all PFs, and calculates the space size of each PF
      according to its function number.
      
      To support this feature, PF driver adds querying multicast MAC address
      space size from firmware and limits used number according to space size.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c56ff48
    • G
      net: hns3: PF support get unicast MAC address space assigned by firmware · e435a6b5
      Guangbin Huang 提交于
      Currently, there are two ways for PF to set the unicast MAC address space
      size: specified by config parameters in firmware or set to default value.
      
      That's mean if the config parameters in firmware is zero, driver will
      divide the whole unicast MAC address space equally to 8 PFs. However, in
      this case, the unicast MAC address space will be wasted a lot when the
      hardware actually has less then 8 PFs. And in the other hand, if one PF has
      much more VFs than other PFs, then each function of this PF will has much
      less address space than other PFs.
      
      In order to ameliorate the above two situations, introduce the third way
      of unicast MAC address space assignment: firmware divides the whole unicast
      MAC address space equally to functions of all PFs, and calculates the space
      size of each PF according to its function number. PF queries the space size
      by the querying device specification command when in initialization
      process.
      
      The third way assignment is lower priority than specified by config
      parameters, only if the config parameters is zero can be used, and if
      firmware does not support the third way assignment, then driver still
      divides the whole unicast MAC address space equally to 8 PFs.
      Signed-off-by: NGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e435a6b5
  7. 13 9月, 2021 2 次提交
  8. 31 8月, 2021 2 次提交
  9. 28 8月, 2021 2 次提交
  10. 27 8月, 2021 2 次提交
  11. 26 8月, 2021 4 次提交
  12. 24 8月, 2021 1 次提交
  13. 17 8月, 2021 1 次提交
  14. 12 8月, 2021 1 次提交
  15. 26 7月, 2021 1 次提交
  16. 20 7月, 2021 1 次提交
  17. 29 6月, 2021 1 次提交
  18. 16 6月, 2021 1 次提交
  19. 12 6月, 2021 1 次提交
  20. 10 6月, 2021 1 次提交
  21. 09 6月, 2021 5 次提交